TLS – 永夜

排查实录：解决Clash Verge + Wstunnel + WireGuard下“部分网站无法访问”的DNS死锁问题

永夜 — Fri, 15 May 2026 03:33:47 +0000

浏览量： 376

问题背景
在《ZgoCloud + Wstunnel + WireGuard 提速 4 倍，Clash Verge Rev 自动分流与 443 端口防封实战》一文发布后，整体代理方案运行稳定，但一个诡异的问题悄然浮现：部分国外网站可以正常访问（如 GitHub、Cloudflare），而另一些则直接报错无法打开。

浏览器给出的错误信息是 `ERR_CONNECTION_CLOSED`，Clash Verge 日志中则反复出现 `context deadline exceeded`。经过一系列排查，最终定位到 DNS 解析死锁——这几乎是此类“部分通、部分不通”问题的典型元凶。本文完整记录从现象到修复的全过程，供遇到类似问题的读者参考。

1. 问题现象
– 可正常访问：`github.com`、`cloudflare.com` 等站点，速度正常。
– 不可访问：`www.google.com` 提示 `ERR_CONNECTION_CLOSED`；`chatgpt.com`、`v2ex.com` 提示 `ERR_CERT_COMMON_NAME_INVALID`（HSTS 导致的证书错误）（如图1）（如图2）。

– Clash 日志特征：`[TCP] dial Proxy … error: context deadline exceeded`，请求在代理层就已超时（如图3）。

– 其他现象：所有被阻断的网站都拥有 HSTS 预加载特性，而正常的网站则没有。

初步判断：问题不在代理隧道本身的连通性（毕竟 GitHub 能走），而更像是在 DNS 解析或 TLS 握手环节被某种机制干扰了。

2. 第一阶段排查：MTU 与 IPv6
2.1 调整 MTU（无效）
由于报错是超时，我首先怀疑是 Wstunnel 封装的 MTU 分片问题。将 WireGuard 客户端的 MTU 从默认 1420 逐步下调至 1100，问题依旧。部分网站仍然无法访问，说明 MTU 并非主因。

2.2 关闭 IPv6（部分缓解，出现证书错误）
在 Clash Verge 的设置中关闭 IPv6 支持（`ipv6: false`）后，部分网站的连接超时问题减轻，但 `chatgpt.com` 等站点开始报 `ERR_CERT_COMMON_NAME_INVALID` 证书错误。证书错误是 DNS 污染的直接表现：浏览器尝试连接 DNS 污染后的错误 IP，对方返回的证书域名与请求不匹配，因此被 Chrome 拦截。

这说明系统 DNS 返回了被污染的结果，且这些请求并未经过代理隧道。原因是 Clash 的 DNS 功能此前被我关闭了（`dns: false`），所有解析都直接使用本地网络提供的 DNS，而这些 DNS 对敏感域名普遍存在投毒。

3. 第二阶段：启用 Clash DNS 并陷入死锁
既然 DNS 污染是主因，最直接的方案就是启用 Clash 内置 DNS，并让境外域名通过代理隧道查询无污染的 DNS 服务器。

3.1 初始 DNS 配置（失败）

dns:
  enable: true
  ipv6: false
  nameserver:
    - https://dns.alidns.com/dns-query    国内域名
  fallback:
    - https://dns.google/dns-query         国外域名，这里埋下隐患
  proxy: ZgoCloud-WG

重启 Clash 后，所有境外网站全部超时，日志显示：

[DNS] resolve ... from https://dns.google:443/dns-query
re-creating the http client due to requesting ... context deadline exceeded

`dns.google` 自身的查询超时了。这就是经典的 DNS 解析死锁：Clash 需要通过 `ZgoCloud-WG` 代理去连接 `dns.google`，但要连接 `dns.google`，首先得解析出它的 IP 地址，而这个解析请求本身又被配置为走 `dns.google`……形成了一个无限的死循环。

3.2 尝试 IP 形式的 DoT（失败）
为了避免域名解析死锁，我将 fallback 改为 Google 的 DNS over TLS (DoT)，使用 IP 地址直接访问：

fallback:
  - tls://8.8.8.8:853

然而，日志显示 `dial tcp 8.8.8.8:853: i/o timeout`。这说明 Wstunnel 隧道对非 HTTP 的 TLS 流量（即 DoT）转发存在问题——Wstunnel 本质上是 WebSocket 隧道，它擅长封装 HTTP/HTTPS，而对纯 TLS 流（端口 853）可能由于封包方式或防火墙限制而无法正常工作。

3.3 最终成功方案：Cloudflare DoT
既然 Google DoT 不通，我换用 Cloudflare 的 `1.1.1.1:853`，并同时做两个关键调整：

1. 保留 IP 直连的 DoT 服务：`tls://1.1.1.1:853`，消除域名解析依赖。
2. 明确指定 DNS 请求走代理节点：使用 `proxy: ZgoCloud-WG`，而非代理组（`Proxy` 或 `Auto`），避免 url-test 误选直连导致超时。
3. 删除直连 dns.google 的规则：原 `rules` 中有一条 `DOMAIN,dns.google,DIRECT`，这会强制 Clash 让 `dns.google` 的解析走直连，与我们的需求相悖，必须移除。
4. 补充排查：Wstunnel 隧道稳定性
在调整 DNS 的过程中，曾一度出现 Clash 日志完全空白的情况，这通常表示 Clash 内核根本没有成功启动。最终发现是不小心导致的乌龙：
– 日志记录被手动暂停：Clash Verge 的日志面板右上角有一个“暂停/继续”按钮，排查时不小心触碰，导致所有日志停止刷新（如图4）。

5. 最终效果
修改后重启 Clash 内核，观察日志：

[DNS] chatgpt.com --> [104.18.2.161 104.18.3.161] A from tls://1.1.1.1:853

所有之前报证书错误或超时的网站（`chatgpt.com`、`v2ex.com`、`google.com`）均能正常打开，`github.com` 等原本正常的网站依然保持快速。问题彻底解决（如图5）。

在 Clash Verge – 首页 – 网站测试 – 测试全部，测试通过（如图7）。

6. 技术总结：为什么你的代理“部分通部分不通”？
– 现象：能打开 GitHub 但打不开 Google，且后者常报证书错误或超时。
– 本质：DNS 污染 + 代理链 DNS 解析死锁。
– 关键点：
1. 不要将 Clash 的 fallback DNS 设置为需要自身解析的域名（如 `dns.google`），应使用 `tls://1.1.1.1` 这类 IP 直连的加密 DNS。
2. DNS 代理策略应精确到节点，避免使用 `url-test` 等可能误判的代理组。
3. Wstunnel 更适合承载 HTTPS 流（DoH），而非纯 TLS 流（DoT）——但实测 Cloudflare 的 `1.1.1.1:853` 可以通过，可能与特定路径有关，可灵活切换。
4. 关闭 IPv6（如图7）和调整 MTU 是辅助手段，但并非根本解药。

5. 检查 HSTS 错误：当浏览器报 `ERR_CERT_COMMON_NAME_INVALID` 时，首先怀疑 DNS 被投毒，而非代理隧道故障。

7. 最终参考配置（完整版，保留所有注释）
以下是我最终使用的订阅配置文件，所有注释均已保留，方便理解每项含义。请务必将密钥、IP 等信息替换为你自己的实际值。

# ==============================================
# 你的自定义订阅配置，会和Clash Verge自带的基础配置自动合并
# ==============================================

# 新增：配置持久化（保存你手动选择的代理组，重启后不会重置）
profile:
  store-selected: true

# DNS配置（自带config没有DNS部分，保留你的原有配置）
dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  default-nameserver:
    - 114.114.114.114
  nameserver:
    - https://dns.alidns.com/dns-query # 国内域名用阿里 DoH
  fallback:
    - tls://1.1.1.1:853 # 国外域名用 Cloudflare 的 DoT（推荐，相对更快）
  # 直接指定代理节点，不要用 url-test 组
  proxy: ZgoCloud-WG
  fallback-filter:
    geoip: true
    ipcidr:
      - 240.0.0.0/4

# 代理配置（修复了缩进错误，修改了remote-dns-resolve）
proxies:
  - name: "ZgoCloud-WG" # 代理的名字，不用改
    type: wireguard # 代理类型，WireGuard
    server: 127.0.0.1 # 本地的wstunnel客户端的地址，不用改
    port: 51820 # 本地的wstunnel客户端的端口，不用改
    ip: 10.7.0.2 # 你的WireGuard客户端的IP，从client.conf里拿到的
    public-key: a4DvxU7LgW0069MbHpMMhcc... # WireGuard的公钥，从client.conf里拿到的
    private-key: yBdtV4+0CxvTFvXWrPS+sM... # WireGuard的私钥，从client.conf里拿到的
    pre-shared-key: 3glNI413OnTF2mAJLo9JSFG... # WireGuard的预共享密钥，从client.conf里拿到的
    remote-dns-resolve: false # 关闭远程解析：server是本地IP，不需要远程解析
    udp: true # 开启UDP转发，支持游戏之类的UDP流量
    mtu: 1100 # 调整MTU，适配wstunnel的封装，避免分片丢包

# 代理分组（保留你的原有配置）
proxy-groups:
  - name: "Proxy" # 手动选择的分组，你可以手动切换直连还是VPN
    type: select
    proxies:
      - ZgoCloud-WG # 走VPN
      - DIRECT # 直连

  - name: "Auto" # 自动选择的分组，自动判断国内国外
    type: url-test
    proxies:
      - ZgoCloud-WG
      - DIRECT
    url: http://www.gstatic.com/generate_204
    interval: 300

# 完善后的分流规则（补充了缺失的规则，所有缩进都改成了空格）
rules:
  # 1. 最高优先级：Wstunnel 服务器直连（解决代理循环）
  - IP-CIDR,154.21.196.249/32,DIRECT

  # 2. DNS 域名必须直连（解决你现在的 DNS 解析失败）
  - DOMAIN,dns.alidns.com,DIRECT

  # 3. 本地局域网直连
  - IP-CIDR,127.0.0.1/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT

  # 4. 国内流量直连
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT

  # 5. 其他全部走代理
  - MATCH,Proxy

结语
这次排查耗时虽长，但最终聚焦到一个简单的 DNS 死锁问题上。对于自建代理而言，DNS 的配置往往比隧道本身更容易踩坑。希望本文的记录能帮助同样在“部分网站打不开”的迷雾中摸索的朋友，少走一些弯路。如果你也有类似的 Clash + WireGuard + Wstunnel 组网经验，欢迎在评论区交流。

在 Windows 10 中安装 Wireshark 后对 Shopify CLI 3.x 的抓包流程

永夜 — Fri, 24 Nov 2023 01:57:48 +0000

浏览量： 121

1、参考：在 Windows 10 中安装 Fiddler Classic 后对 Shopify CLI 3.x 的抓包流程。参考：在 Windows 10 中安装 Fiddler Everywhere 后对 Shopify CLI 3.x 的抓包流程。皆以失败告终。 2、选择网络接口：从 Wireshark 主窗口中，选择 Shopify CLI 流量将通过的网络接口。由于我的是笔记本电脑，通过 Wi-Fi 连接网络，因此选择 WLAN，点击按钮：开始捕获分组。如图1

图1

3、在终端中执行中 Shopify CLI 的命令，以请求获取主题列表。如图2

图2



PS E:\wwwroot\shopify-theme\theme-20230922> shopify theme list --verbose
2023-10-09T08:05:28.924Z: Running command theme list
2023-10-09T08:05:28.955Z: Ensuring that the user is authenticated with the Theme API with the following scopes:
[]

2023-10-09T08:05:28.956Z: Ensuring that the user is authenticated with the Admin API with the following scopes for the store shuijingwanwq-development.myshopify.com:
[]

2023-10-09T08:05:28.958Z: Getting session store...
2023-10-09T08:05:28.965Z: Validating existing session against the scopes:
[
  "openid",
  "https://api.shopify.com/auth/shop.admin.graphql",
  "https://api.shopify.com/auth/shop.admin.themes",
  "https://api.shopify.com/auth/partners.collaborator-relationships.readonly",
  "https://api.shopify.com/auth/shop.storefront-renderer.devtools",
  "https://api.shopify.com/auth/partners.app.cli.access",
  "https://api.shopify.com/auth/destinations.readonly"
]
For applications:
{
  "adminApi": {
    "scopes": [],
    "storeFqdn": "shuijingwanwq-development.myshopify.com"
  }
}

2023-10-09T08:05:28.967Z: Sending Identity Introspection request to URL: https://accounts.shopify.com/oauth/introspection
2023-10-09T08:05:28.969Z: Sending POST request to URL https://accounts.shopify.com/oauth/introspection
With request headers:
 - User-Agent: Shopify CLI; v=3.49.3
 - Keep-Alive: timeout=30
 - Sec-CH-UA-PLATFORM: win32
 - Content-Type: application/json

2023-10-09T08:05:30.037Z: Request to https://accounts.shopify.com/oauth/introspection completed in 1044 ms
With response headers:
 - cache-control: no-cache, no-store, private, must-revalidate, max-age=0
 - content-type: application/json; charset=utf-8
 - etag: W/"7d98625ff90e9b2d78e0e2a444b14481"
 - x-request-id: 72585f47-91c2-4944-81b7-8349d2ab8cbf

2023-10-09T08:05:30.057Z: The identity token is valid: true
2023-10-09T08:05:30.058Z:
The validation of the token for application/identity completed with the following results:
- It's expired: false
- It's invalid in identity: false

2023-10-09T08:05:31.155Z: Request to https://shuijingwanwq-development.myshopify.com/admin/api/unstable/themes.json?fields=id%2Cname%2Crole%2Cprocessing completed in 1089 ms
With response headers:
 - content-type: application/json; charset=utf-8
 - x-request-id: bb9a9fa0-d8e7-4374-ba47-4d9a6c0b10d0

2023-10-09T08:05:31.166Z: Getting development theme...
2023-10-09T08:05:31.170Z: Getting host theme...
name                                             role                   id
───────────────────────────────────────────────  ─────────────────────  ─────────────
Dawn 的更新版副本                                      [live]                 #133644189881
Dawn                                             [unpublished]          #130440429753
Sense                                            [unpublished]          #130698641593
Crave 重命名                                        [unpublished]          #130935947449
Refresh                                          [unpublished]          #131376218297
Colorblock                                       [unpublished]          #131376251065
Dawn Customize                                   [unpublished]          #130580054201
Taste 的更新版副本 的更新版副本 的更新版副本 的更新版副本 的更新版副本 的更新版副本 [unpublished]          #132350771385

shopify-theme-dawn-20221011/main                 [unpublished]          #133060722873
Dawn                                             [unpublished]          #133474844857
Copy of Studio                                   [unpublished]          #133474975929
Dawn (Shopify CLI) 9                             [unpublished]          #133492932793
Dawn 的副本 的副本 1                                   [unpublished]          #133635932345
Colorblock                                       [unpublished]          #130698510521
Taste                                            [unpublished]          #130698543289
Craft                                            [unpublished]          #130698576057
Development (639b5c-DESKTOP-QLPK8QM)             [development] [yours]  #134109462713
2023-10-09T08:05:31.442Z:
Running system process:
  · Command: ruby -v
  · Working directory: E:/wwwroot/shopify-theme/theme-20230922

2023-10-09T08:05:33.063Z: Request to https://monorail-edge.shopifysvc.com/v1/produce completed in 1582 ms
With response headers:
 - x-request-id: 73b18bad-4378-4711-b2de-05386d867fa3

2023-10-09T08:05:33.066Z: Analytics event sent: {
  "command": "theme list",
  "time_start": 1696838728927,
  "time_end": 1696838731391,
  "total_time": 2464,
  "success": true,
  "cli_version": "3.49.3",
  "ruby_version": "3.1.1",
  "node_version": "18.18.0",
  "is_employee": false,
  "uname": "windows amd64",
  "env_ci": false,
  "env_plugin_installed_any_custom": false,
  "env_plugin_installed_shopify": "[\"@shopify/cli\",\"@shopify/plugin-did-you-mean\",\"@shopify/theme\"]",
  "env_shell": "cmd.exe",
  "env_device_id": "eb479d42673daf065d783e808d3de3b4870a4c02",
  "env_cloud": "localhost",
  "env_package_manager": "unknown",
  "cmd_all_launcher": "unknown",
  "cmd_all_topic": "theme",
  "cmd_all_plugin": "@shopify/theme",
  "cmd_all_verbose": true,
  "cmd_all_path_override": false,
  "args": "--verbose",
  "env_plugin_installed_all": "[\"@shopify/cli\",\"@shopify/plugin-did-you-mean\",\"@shopify/theme\"]",
  "metadata": "{\"extraPublic\":{},\"extraSensitive\":{}}"
}
2023-10-09T08:05:33.071Z: Completed command theme list
PS E:\wwwroot\shopify-theme\theme-20230922>

4、点击按钮：停止捕获分组。如图3

图3

5、通过 ping shuijingwanwq-development.myshopify.com 获取到对应的 IP 地址：23.227.38.74。如图4

图4



PS E:\wwwroot\shopify-theme\theme-20230922> ping shuijingwanwq-development.myshopify.com

正在 Ping shops.myshopify.com [23.227.38.74] 具有 32 字节的数据:
来自 23.227.38.74 的回复: 字节=32 时间=207ms TTL=50
来自 23.227.38.74 的回复: 字节=32 时间=209ms TTL=50
来自 23.227.38.74 的回复: 字节=32 时间=250ms TTL=50
来自 23.227.38.74 的回复: 字节=32 时间=204ms TTL=50

23.227.38.74 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 204ms，最长 = 250ms，平均 = 217ms

6、在 Source 中找到：23.227.38.74，右键 – 作为过滤器应用 – 选中。如图5

图5

7、仅剩下 Source 为 23.227.38.74 的请求记录。协议中竟然不存在 HTTP，是 TCP 与 TLSv1.3，并且响应是密文。如图6

图6

8、参考：Transport Layer Security (TLS)。密钥日志文件是一种通用机制，即使正在使用 Diffie-Hellman (DH) 密钥交换，它也始终能够解密。 9、添加 SSLKEYLOGFILE 用户变量，可以指定浏览器在访问 SSL/TLS 网站时将对应的密钥保存到本地文件中，其值为：E:\Develop\SSLKEYLOGFILE\key.log。此机制目前（2019 年）不适用于 Safari、Microsoft Edge 和其他浏览器，因为它们的 TLS 库（Microsoft SChannel/Apple SecureTransport）不支持此机制。此机制也适用于 Web 浏览器以外的应用程序，但它依赖于应用程序使用的 TLS 库。注意：基于 Chrom 的 Edge 版本（版本 79+）也应该可以工作。如图7

图7

10、配置 Wireshark，编辑 – 首选项 – Protocls – TLS。(Pre)-Master-Secret 日志文件名 (tls.keylog_file)：读取 TLS 密钥日志文件以进行解密的路径。TLS 调试文件 (tls.debug_logfile)：写入有关解密过程的内部详细信息的路径。将包含解密结果以及此过程中使用的密钥。这可以用来诊断解密失败的原因。如图8

图8

11、启用 TLS 解密还需要以下 TCP 协议首选项：Allow subdissector to reassemble TCP streams(允许细分器重新组装 TCP 流)。默认启用。Reassemble out-of-order segments(重新组装无序段)（从 Wireshark 3.0 开始，默认禁用）需要启用。如图9

图9

12、确认浏览器已被完全关闭，可通过查看任务管理器再次确认。在终端中执行了相应命令后，查看捕获的流量，仍然与第 7 步骤类似，TLS 没有被解密。虽然两个日志的更新时间发生了变化。如图10

图10

13、不过在 Chrome 浏览器中访问：shuijingwanwq-development.myshopify.com 。查看捕获的流量，已经显示为 HTTP3，虽然仍然是密文。不符合预期。如图11

图11

14、现在需要解密 HTTP3，在浏览器中导出证书。如图12

图12

15、配置 Wireshark，编辑 – 首选项 – Protocls – TLS。决定暂时搁置此方案，因为已经找到了更为合适的方案。参考：在 Windows 10 中安装 HTTP Toolkit 后对 Shopify CLI 3.x 的抓包流程