Roxi先把“进来”和“出去”分开
系统代理和 TUN 主要解决流量怎样进入客户端；规则模式或全局模式决定进入后的流量怎样选择出口。开启 TUN 并不自动等于所有应用、IPv6、DNS 都走海外节点，规则里仍可存在直连和排除。反过来，全局模式也不会自动抓到忽略系统代理的应用。
| 方式 | 入口特点 | 常见适用场景 |
|---|---|---|
| 系统代理 | 由遵守系统设置的应用主动使用本地代理 | 浏览器和支持系统代理的软件 |
| 应用单独配置 | 该应用指定 HTTP/SOCKS 等入口 | 终端或有独立代理选项的软件 |
| TUN / VPN 接管 | 通过虚拟网络接口与路由捕获所覆盖流量 | 需要接管不读取系统代理的应用 |
覆盖范围取决于系统、路由和客户端实现。Android 的 VPN API 还允许包含或排除应用；桌面客户端也可能排除网段和网卡。因此“浏览器出口变了”只能证明该浏览器的一次请求，不能证明整机无遗漏。
按需求选最小可用方案
- 只有浏览器需要代理时，先使用客户端提供的系统代理，并检查扩展是否另设代理。
- Git、curl 或某个独立软件失败时，先看它有没有明确的代理参数或环境设置，结合站内对应教程配置。
- 确实需要更广泛接管时，再启用客户端支持的 TUN 服务或移动端 VPN；按官方流程授予必要权限。公司设备先确认允许的设置范围。
系统代理与 TUN 在某些客户端可以协同存在，并不是绝对不能同时开。但初次定位故障时，先逐一验证两种入口更容易找出问题。不要同时调整 DNS、规则、内核和多个 VPN 服务。
做一次不修改系统的显式请求对照
下例是 Windows PowerShell，7890 为本地 HTTP/mixed 端口示例。第一条显式走该入口，第二条不使用 curl 的显式代理；macOS/Linux 改用 curl 与 /dev/null。两条均为普通 GET，不需要管理员权限。
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 8 --max-time 20 -o NUL -w "http=%{http_code}\n" https://example.com
curl.exe --noproxy "*" --connect-timeout 8 --max-time 20 -o NUL -w "http=%{http_code}\n" https://example.com显式代理成功而浏览器失败，先查浏览器及系统入口；系统代理可用但某应用失败，再查应用是否遵守设置。TUN 开启后成功也不是充分证据：结合连接记录中该应用或域名、命中规则、实际出口一起判断。
TUN 出现副作用时，按现象撤回
| 副作用 | 优先核对 | 恢复动作 |
|---|---|---|
| 打印机或 NAS 不通 | 局域网路由、排除范围与解析 | 先关 TUN 对照，保留原规则 |
| 域名失败，部分连接正常 | DNS 接管、私人 DNS 和网络分域 | 恢复刚改的 DNS 项后复测 |
| 虚拟机或企业内网异常 | 路由重叠、网卡与严格路由 | 回退 TUN；组织网络按管理员方案处理 |
| 停止 VPN 后移动端断网 | 系统是否阻止无 VPN 连接 | 按自身需求恢复原阻断策略 |
不要把 netsh winhttp show proxy 的结果当作所有 Windows 应用的统一状态；它查询的是 WinHTTP。TUN、浏览器代理和其他网络栈有各自的路径。也不要看到 DNS 问题就复制一整份未知配置覆盖当前订阅。
完成验证与正常退出
- 用日常规则测试浏览器、原来失败的应用和必要内网服务。IPv6、DNS 与隐私要求另按泄露检查教程验证。
- 在客户端正常关闭 TUN 并清除自己设置的系统代理，再从托盘退出；不要只结束窗口。
- 重新访问可直连网站，确认没有遗留代理。若还有故障，保留原配置并按 Windows 或 Mac 网络恢复教程逐项检查。