问题排查 on YSY的博客

Clash Verge 开启 TUN 后一元机场节点全部超时的解决办法

Tue, 04 Aug 2026 00:00:00 +0000

本文记录 Windows 电脑端 Clash Verge 开启 TUN 后，一元机场节点全部超时的排查与解决过程：订阅能正常更新、自建节点也能使用，唯独机场节点在 TUN 模式下几乎全部 Timeout。最终根因与 TUN 堆栈、DNS、IPv6 以及机场节点的 XHTTP 传输方式共同相关。

1. 故障现象

使用环境：Windows + Clash Verge 2.5.2 + Mihomo v1.19.29，规则模式，TUN 虚拟网卡接管，机场节点为 VLESS + TLS + XHTTP（stream-up 模式，端口 443）。

故障表现：

Clash Verge 正常启动，机场订阅正常更新，流量、到期时间正常显示，节点完整加载。
代理页面测速时几乎所有节点都显示 Timeout 或 Error，自动选择与故障转移也无法找到可用节点。
同一订阅在朋友电脑上正常；同一台电脑使用自建节点则正常。

由此可排除：机场整体宕机、订阅链接过期、流量耗尽、节点全部失效、账号被封、客户端版本差异。

节点测速页面截图

2. 关键判断：问题出在 TUN 接管后的链路

订阅更新与节点连接是两条独立的网络路径：能更新订阅只说明订阅服务器可访问，不代表节点能连上。

初步验证时关闭 TUN、改用系统代理（同时关闭 IPv6）后，日本、香港等大量节点立刻恢复延迟。这说明：

机场节点并没有失效，账号和订阅参数基本正常；
电脑可以直接连接机场服务器；
故障主要出现在 TUN 接管流量之后，集中在 TUN 堆栈、路由、DNS 劫持、IPv6 或虚拟网卡环节。

自建节点在 TUN 下正常而机场节点超时也不矛盾：机场 XHTTP 节点同时涉及主连接域名和 download-settings 中的下载域名，需要维持多条 TCP/TLS/XHTTP 长连接，对 TUN 协议栈和 DNS 解析的敏感度远高于普通自建节点。

3. 解决办法

3.1. 先用系统代理验证问题范围

将设置调整为：

TUN 虚拟网卡模式：关闭
系统代理：开启
IPv6：关闭
DNS 覆写：关闭
代理模式：规则

如果节点恢复延迟，即可确认故障在 TUN 接管链路，而不是节点或账号问题。

3.2. 将 TUN 堆栈切换为 Mixed

Clash Verge 的 TUN 设置中有三种堆栈：

GVisor：TCP 和 UDP 都由 Mihomo 内置的用户态协议栈处理
System：TCP 和 UDP 都走 Windows 原生协议栈
Mixed：TCP 走 Windows 原生协议栈，UDP 走 GVisor 用户态协议栈

机场 XHTTP 的 TLS 长连接主要依赖 TCP，从 GVisor 切换为 Mixed 后，TCP 连接改由 Windows 原生协议栈处理，兼容性更好。

注意：仅切换堆栈只是短暂恢复，一段时间后节点会再次全部超时，说明根因不只是协议栈，还需要配合下一步修正 DNS 配置。

3.3. 修正 DNS 覆写配置（核心）

原 DNS 覆写配置存在几个问题：

主设置已关闭 IPv6，但 DNS 覆写中 ipv6: true 且配置了 IPv6 DNS，DNS 返回 AAAA 记录后 Mihomo 尝试走不稳定的 IPv6 出口，导致连接超时。
default-nameserver 混用 system、阿里 DNS、Google DNS、IPv6 DNS，不同来源解析结果不一致。
proxy-server-nameserver 使用 DoH 域名，解析链路复杂。
listen: ':53' 可能与 TUN 的 dns-hijack: any:53 或 Windows 上其他占用 53 端口的服务冲突。

修正要点：

ipv6: false，去掉 IPv6 DNS 条目
listen 改为 0.0.0.0:1053，避开 53 端口
default-nameserver 统一为国内公共 DNS（如 223.5.5.5）
开启 use-hosts 和 use-system-hosts
fake-ip-filter 保留本地域名、NTP 和系统连通性探测域名

将 DNS 覆写配置整体替换为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


dns:
 enable: true
 listen: '0.0.0.0:1053'
 enhanced-mode: 'fake-ip'
 fake-ip-range: '198.18.0.1/16'
 fake-ip-range6: 'fdfe:dcba:9876::1/64'
 fake-ip-filter-mode: 'blacklist'
 prefer-h3: false
 respect-rules: false
 use-hosts: true
 use-system-hosts: true
 ipv6: false
 fake-ip-filter:
 - '*.lan'
 - '*.local'
 - '*.arpa'
 - 'time.*.com'
 - 'ntp.*.com'
 - '+.market.xiaomi.com'
 - 'localhost.ptlogin2.qq.com'
 - '*.msftncsi.com'
 - 'www.msftconnecttest.com'
 default-nameserver:
 - '223.5.5.5'
 - '119.29.29.29'
 nameserver:
 - 'https://doh.pub/dns-query'
 - 'https://dns.alidns.com/dns-query'
 direct-nameserver-follow-policy: false
 fallback-filter:
 geoip: true
 geoip-code: 'CN'
 ipcidr:
 - '240.0.0.0/4'
 - '0.0.0.0/32'
 domain:
 - '+.google.com'
 - '+.facebook.com'
 - '+.youtube.com'
 fallback: []
 proxy-server-nameserver:
 - '223.5.5.5'
 - '119.29.29.29'
 direct-nameserver:
 - 'https://doh.pub/dns-query'
 - 'https://dns.alidns.com/dns-query'

4. 验证结果

按上述步骤调整后（TUN 开启、堆栈 Mixed、IPv6 关闭、DNS 覆写使用修正后的配置），一元机场节点恢复稳定延迟，TUN 模式下可正常访问网络。

5. 总结

遇到"订阅能更新、节点却全部超时"时，不要急着怀疑节点失效，按以下顺序排查：

关闭 TUN、开启系统代理验证，确认问题是否出在 TUN 接管链路。
将 TUN 堆栈切换为 Mixed，让 TCP 走 Windows 原生协议栈，改善 XHTTP 长连接兼容性。
修正 DNS 覆写：关闭 IPv6、统一 default-nameserver、监听端口避开 53、开启 hosts 支持。

机场的 XHTTP 节点链路复杂，对 TUN 堆栈和 DNS 解析更敏感，以上三项需要配合调整才能彻底解决。

ChatGPT 频繁「正在重新连接」？开启 Clash TUN 模式即可解决

Mon, 13 Jul 2026 00:00:00 +0000

1. 问题现象

使用 ChatGPT 时，界面顶部频繁弹出 正在重新连接，往往连续重试四五次，看起来已经无法正常使用了。但稍等片刻后，回复又会突然正常输出。

这种「先失败、后恢复」的表现容易让人误以为是网络波动或 ChatGPT 服务端不稳定。

2. 原因分析

问题通常出在代理配置上，而非 ChatGPT 本身。

ChatGPT 优先通过 WebSocket 与服务器保持长连接，以实现流式输出。在仅开启系统代理、未启用 TUN 模式的情况下，Clash 往往只能接管浏览器走 HTTP 代理的那部分流量，WebSocket 连接不一定能稳定经过代理，于是反复握手失败，界面便不断显示「正在重新连接」。

多次重试之后，客户端会 降级为普通 HTTP 请求 拉取回复。HTTP 走代理通常没有问题，所以最终又能看到正常输出——给人一种「快放弃了又好了」的错觉。

3. 解决方案：开启 Clash TUN 模式

TUN 模式在系统网络层接管全部流量，WebSocket 与 HTTP 都会经过 Clash 路由，长连接不再频繁中断。

3.1. 操作步骤

以 Clash Verge 为例：

打开 Clash Verge，确保代理已正常运行
进入设置，找到 TUN 模式（或 虚拟网卡模式）
开启 TUN 模式，按提示授予管理员权限（Windows 首次开启需要）
重新打开 ChatGPT 页面，发起一次对话验证

若使用其他 Clash 客户端（如 Clash for Windows、Clash Meta 等），同样在设置中开启 TUN / 增强模式即可，名称可能略有不同。

4. 总结

现象	原因	解决
频繁「正在重新连接」	WebSocket 未稳定走代理	开启 Clash TUN 模式
重试多次后又能用	客户端降级为 HTTP	同上，无需额外操作

开启 TUN 模式后，ChatGPT 的 WebSocket 长连接可以稳定经代理转发，流式输出不再反复断连。

PC 端《三角洲行动》启动画面放大、纯色闪屏的解决方案

Thu, 05 Mar 2026 00:00:00 +0000

💡 前言：如果你第一次启动《三角洲行动》时遇到画面放大或纯色闪屏，别慌！这是 Windows 高 DPI 缩放与游戏引擎的冲突。本文提供解决方案。

1. 🔍 问题现象

第一次启动《三角洲行动》时可能遇到以下问题：

画面异常放大：游戏图像被放大多倍，只能看到界面的一小部分，鼠标无法点击目标按钮
“假花屏”：能听到游戏音效，但屏幕显示单一颜色交替闪动，不显示游戏内容
反复重启才能进：遇到上述情况只能强退，需多次重启才能正常进入

2. 🔍 问题原因

这不是显卡故障，而是 Windows 高 DPI 缩放与游戏引擎的冲突。

使用 2.5K 或更高分辨率屏幕时，Windows 默认开启 125% 或 150% 系统缩放。游戏启动时，引擎未能正确接管屏幕，Windows 将系统缩放强加在全屏游戏画面上，造成"二次放大"，导致渲染出错，表现为画面缩小或纯色闪屏。

3. 🛠️ 解决方案：NVIDIA 应用设置

3.1 详细步骤

打开电脑上的 NVIDIA 应用（NVIDIA App），在左侧导航栏点击图形选项卡。

在程序列表中找到并点击 三角洲行动（Delta Force）。

在右侧找到 游戏已优化 选项，点击恢复按钮后面的小三角展开详细设置。

在展开的设置面板中，找到 显示模式 选项，在下拉菜单中选择 无边框窗口化。

设置完成后无需额外保存，直接关闭 NVIDIA 应用即可。

4. ✅ 验证效果

重新打开游戏，画面应该能正常显示，不再出现放大或纯色闪屏问题。

如果问题仍然存在，可以尝试重启电脑后再启动游戏。

5. 📝 总结

《三角洲行动》启动时的画面放大和纯色闪屏问题，本质上是 Windows 高 DPI 缩放与游戏引擎的冲突。

通过 NVIDIA 应用将显示模式设置为 无边框窗口化，可以让游戏正确接管画面渲染，彻底解决问题。这种方法简单快捷，无需修改任何文件属性。

希望这篇文章能帮助到遇到同样问题的朋友！如果还有什么新的方法，欢迎在评论区留言交流。