104 lines
12 KiB
Markdown
104 lines
12 KiB
Markdown
浏览器能打开网页，终端却一直超时；已经切到“全局”，游戏还是连不上；打开 TUN 后能用了，又担心所有网站都被送到国外。遇到这些情况，先分清两件事：**流量有没有进入代理客户端，以及进入以后走哪个出口。**
|
||
|
||
系统代理和 TUN 主要解决第一件事，规则、全局和直连模式主要解决第二件事。本文以 Clash Verge Rev 和 Mihomo 桌面客户端为例，说明它们的区别、适用场景和检查方法。
|
||
|
||
<nav class="guide-toc" aria-label="文章目录"><strong>阅读路线</strong><a href="#system-proxy">系统代理接管什么</a><a href="#tun">TUN 改变了什么</a><a href="#routing">为什么全局不等于全部</a><a href="#choose">应该用哪一种</a><a href="#switch">怎样切换和检查</a><a href="#troubleshoot">按现象排错</a><a href="#dns">DNS 还要单独看</a></nav>
|
||
|
||
<h2 id="system-proxy">01 系统代理：让应用按设置转交请求</h2>
|
||
|
||
打开 Clash Verge Rev 的“系统代理”，客户端会修改操作系统的代理设置，把代理地址指向本机正在监听的端口。愿意读取并遵循这项设置的应用，就会把相应请求交给客户端处理。浏览器通常可以通过这种方式使用代理。[官方快速入门](https://www.clashverge.dev/guide/quickstart.html)
|
||
|
||
这里的关键是“应用遵循设置”。有的软件读取系统设置，有的软件使用自己的代理配置，还有的软件直接建立连接。同一台电脑上，浏览器正常、另一个应用不走代理，并不矛盾。
|
||
|
||
<figure class="guide-diagram"><div class="diagram-label">图 1 · 系统代理依赖应用配合</div><div class="guide-flow"><div><b>应用读取设置</b><small>使用系统指定的代理</small></div><span aria-hidden="true">→</span><div><b>本机代理端口</b><small>请求进入 Mihomo</small></div><span aria-hidden="true">→</span><div><b>匹配出口</b><small>直连或代理节点</small></div></div><div class="guide-branch">不遵循系统代理的应用：仍按自己的网络设置连接，不会仅因这个开关而进入 Mihomo。</div><figcaption>这也解释了为什么“浏览器能用”不能代表电脑上每个应用都已经走代理。</figcaption></figure>
|
||
|
||
如果应用提供 HTTP 或 SOCKS 代理选项，可以单独指向客户端的本机端口。地址通常是 <code>127.0.0.1</code>，端口应查看客户端当前设置，不要照抄别人的数字；HTTP、SOCKS 和混合端口也要对应正确。
|
||
|
||
终端工具同样需要看各自支持什么。以 Linux 上的 curl 为例，可以先用[单条命令指定代理的方法](/a/m174.html#terminal)检查，不必为了一个工具马上接管整台电脑。
|
||
|
||
<h2 id="tun">02 TUN：通过虚拟网卡接收流量</h2>
|
||
|
||
TUN 会创建虚拟网络接口，并通过路由把符合接管条件的 IP 流量交给内核。应用不必先学会使用 HTTP 或 SOCKS 代理，因此它常用于系统代理无法覆盖的程序。Mihomo 可以处理通过 TUN 进入的 TCP、UDP 流量，但最终能否完成连接，还取决于配置、节点和目标服务。[官方名词解释](https://www.clashverge.dev/guide/term.html)
|
||
|
||
<figure class="guide-diagram"><div class="diagram-label">图 2 · TUN 在网络路由这一层接管</div><div class="guide-flow"><div><b>应用发起连接</b><small>无需读取系统代理</small></div><span aria-hidden="true">→</span><div><b>系统路由 → TUN</b><small>进入虚拟网卡</small></div><span aria-hidden="true">→</span><div><b>Mihomo 处理</b><small>再决定实际出口</small></div></div><div class="guide-branch">被排除的地址、接口或其他未进入 TUN 的连接，仍可能走原来的网络路径。</div><figcaption>TUN 扩大了接管范围，但开关亮着不等于每一条连接都已被接管。</figcaption></figure>
|
||
|
||
TUN 也有接管范围。自动路由、排除网段、IPv6 设置及其他 VPN 的路由，都可能影响实际路径。例如，把某个局域网网段排除在 TUN 之外，就是让它绕过这层接管；这与连接进入 Mihomo 后命中 <code>DIRECT</code> 规则不同。[Mihomo TUN 配置](https://wiki.metacubex.one/config/inbound/tun/)、[代理绕过说明](https://www.clashverge.dev/guide/bypass.html)
|
||
|
||
日常使用图形客户端时，优先使用它提供的 TUN 设置。建立网卡和修改路由需要相应权限；Clash Verge Rev 的服务模式可让具有权限的后台服务启动内核，不代表必须一直以管理员身份运行整个界面。[服务模式说明](https://www.clashverge.dev/guide/term.html)
|
||
|
||
<h2 id="routing">03 “全局”和 TUN 不是同一个维度</h2>
|
||
|
||
把“规则”改成“全局”，改变的是进入内核后的出口选择。一个完全没有进入客户端的应用，不会因为切到全局就自动被接管。
|
||
|
||
反过来，开启 TUN 也不要求使用全局模式。**TUN + 规则模式**可以接管更多应用，同时继续按规则让部分连接直连、部分连接使用节点。[规则与全局模式说明](https://www.clashverge.dev/guide/term.html)
|
||
|
||
<figure class="guide-diagram"><div class="diagram-label">图 3 · 先进入客户端，再决定去哪里</div><div class="guide-flow"><div><b>第一步：接管</b><small>系统代理 / 应用代理 / TUN</small></div><span aria-hidden="true">→</span><div><b>第二步：选择出口</b><small>规则 / 全局 / 直连</small></div><span aria-hidden="true">→</span><div><b>第三步：建立连接</b><small>本地网络或所选节点</small></div></div><figcaption>排错也按这个顺序进行：先找有没有进入，再看实际出口，最后判断线路是否可用。</figcaption></figure>
|
||
|
||
| 常见组合 | 实际含义 |
|
||
|---|---|
|
||
| 系统代理 + 规则 | 遵循系统代理的请求进入客户端，再按当前配置分流 |
|
||
| 系统代理 + 全局 | 进入内核的普通业务连接使用全局策略；未被接管的应用仍可能绕过 |
|
||
| TUN + 规则 | 被 TUN 接管的连接按规则选择出口，并非全部使用代理节点 |
|
||
| TUN + 全局 | 被接管的普通业务连接使用全局策略；仍需查看所选策略是否为可用节点 |
|
||
|
||
一个具体例子：浏览器和下载工具访问同一域名，浏览器连接记录里显示了节点，下载工具却没有记录。此时应优先检查下载工具的代理设置或接管方式；反复切换全局，通常没有解决前面的缺口。
|
||
|
||
<h2 id="choose">04 按应用需求选择，不必一开始全部打开</h2>
|
||
|
||
| 你要完成的事 | 可以先这样做 |
|
||
|---|---|
|
||
| 主要浏览网页，常用软件已经正常 | 使用系统代理 + 规则模式 |
|
||
| 只有一个应用不跟随系统设置，且自带代理选项 | 给该应用配置正确的本机代理端口 |
|
||
| 多个应用不支持代理设置，希望统一处理 | 考虑 TUN + 规则模式，再逐个检查所需应用 |
|
||
| 游戏或语音涉及 UDP | 检查 TUN 接管，同时确认所选节点支持所需 UDP 转发 |
|
||
| 需要同时访问公司 VPN、NAS 或局域网设备 | 先明确这些连接的路径，再设置绕过或直连，避免盲目全局接管 |
|
||
|
||
**TUN 不是加速档位。** 游戏登录网页能打开，不代表游戏数据传输已经正常；节点对网页可用，也不代表它能承载所需的 UDP。选择方式要看应用连接是否按预期工作，而不是哪个开关听起来更强。
|
||
|
||
系统代理和 TUN 可以同时存在，但两个开关都开不代表效果翻倍。应用主动交给本机端口的请求，本来就已进入客户端；其他连接可能由 TUN 接管。排错时，先明确正在验证哪条路径，比同时改动多个设置更容易找到原因。
|
||
|
||
<h2 id="switch">05 从系统代理切到 TUN，怎样确认有效</h2>
|
||
|
||
先确保客户端已经导入配置、选中可用节点，并完成基本连接。尚未完成这一步，可以按对应平台的教程操作：[Windows](/a/clash-verge-rev-windows.html#enable)、[Mac](/a/m173.html#enable)、[Linux](/a/m174.html#connect)。
|
||
|
||
1. **记录原来的设置。** 包括系统代理、TUN 开关和当前代理组。保持订阅、节点和规则模式不变，便于对比。
|
||
2. **按客户端提示启用服务和 TUN。** 若开关自动关闭或提示权限错误，先处理服务状态与具体错误，不要继续叠加 DNS、协议栈等改动。
|
||
3. **排除其他入口的干扰。** 若要确认某个应用是否由 TUN 接管，暂时关闭本客户端的系统代理，并检查该应用是否另设了代理；有的话记录原值，再临时停用。只关闭系统代理，不能排除应用自己的代理设置。
|
||
4. **让目标应用发起新连接。** 重连应用或重新打开目标内容，避免只观察缓存页面和原有长连接。
|
||
5. **查看连接记录。** 按域名、目标 IP 或可用的进程信息定位请求，查看匹配规则、出口策略，以及界面或日志提供的入站信息。应走节点的请求如果显示 DIRECT，需要回到分流规则检查。
|
||
6. **检查日常需要的本地服务。** 包括局域网设备、公司内网等；确认没有因路由变化失去访问能力，再保留这套设置。
|
||
|
||
关掉系统代理后应用仍能联网，只能说明它不依赖刚才关闭的那项设置。还要结合新连接记录和实际出口，才能判断 TUN 是否按预期接管；应用本来就能直连时，单凭“能打开”尤其容易误判。
|
||
|
||
如果切换后异常，先关闭 TUN，恢复刚才记录的系统代理和应用设置，让连接回到原先可用的状态，再按下一节定位。
|
||
|
||
<h2 id="troubleshoot">06 按现象定位，少做无关改动</h2>
|
||
|
||
### 浏览器能用，终端或另一个应用不能用
|
||
|
||
先检查该应用是否跟随系统代理，或者是否需要独立配置。观察它发起新请求时，客户端有没有相应连接记录。记录里没有出现时，先清除列表筛选、重试并查看日志，排查接管问题；已经出现时，再看命中的规则和实际出口。
|
||
|
||
### 开了 TUN，流量仍显示 DIRECT
|
||
|
||
DIRECT 表示这条连接由客户端直连，并不等于 TUN 没有工作。检查它是否命中了局域网、国内地址等直连规则，或代理组本身选中了 DIRECT。需要改变的是对应出口策略，而不是反复重启虚拟网卡。
|
||
|
||
### 网页正常，游戏或语音仍然失败
|
||
|
||
把登录请求和实时数据连接分开看。后者可能使用不同的地址、端口和 UDP。确认目标连接已进入客户端，再检查节点是否支持相关转发；网页测试成功不能代替这项检查。
|
||
|
||
### 一开 TUN，局域网、公司 VPN 或整个网络就异常
|
||
|
||
先恢复原先可用的方式，再检查路由重叠、网段冲突和客户端日志。系统代理绕过、TUN 路由排除与内核 DIRECT 规则各自发生在不同位置，不应混为一谈。不要把删除网卡或关闭全部防火墙作为第一步。[代理绕过说明](https://www.clashverge.dev/guide/bypass.html)、[Windows TUN 常见问题](https://www.clashverge.dev/faq/windows.html)
|
||
|
||
### 关闭系统代理，连接却还在走节点
|
||
|
||
检查 TUN 是否仍开启，以及应用自己的代理设置是否仍生效。想停用本客户端的接管，应同时处理实际启用的入口，并重新建立连接。关闭窗口可能只是把客户端收进托盘，也不等于退出。
|
||
|
||
<h2 id="dns">07 TUN 能接管流量，DNS 仍要单独检查</h2>
|
||
|
||
访问网站的连接和解析域名的查询，可能走不同路径。TUN 已经开启，并不能直接推出“DNS 一定经过节点”。普通 DNS 是否被接管、应用是否使用独立的加密 DNS，以及解析服务连接走直连还是代理，都需要分别看。
|
||
|
||
例如，浏览器使用 DoH 时，查询本身是加密的 HTTPS 连接。它可能经 TUN 进入内核，但不会仅因一条针对 53 端口的 DNS 劫持设置，就自动变成 Mihomo 内置 DNS 处理的查询。相关字段和平台差异见[Mihomo TUN 配置](https://wiki.metacubex.one/config/inbound/tun/)。
|
||
|
||
想继续检查解析路径，可以阅读[DNS 防泄漏配置与验证](/a/mihomo-dns-leak.html#dns-2)。日常排查时，先确认应用连接进入了哪里，再看它选了什么出口，最后补上 DNS 这条路径，通常比不断切换“系统代理、TUN、全局”更有效。
|