在日常使用网络订阅服务的过程中，很多访客都曾遇到过令人费解的「偏科」现象：同一台电脑连着同一个无线网络，Chrome 浏览器打开网页响应迅速，但另一个桌面软件或命令行工具却始终提示连接超时；又或者同一个应用在手机端加载顺畅，切回电脑端却报错无法解析域名。要理解这种差异，我们需要认识应用发起请求时所经历的 DNS 解析、系统代理接管与传输路径 三个关键环节。
环节一：DNS 解析通道与多级缓存的差异
当我们输入一个网址或打开应用时，设备首先要通过 DNS（域名系统） 将人类可读的域名转换为服务器 IP 地址。看似简单的一步，在不同软件内部却可能走完全不同的路径：
- 操作系统级 DNS 与缓存：操作系统会将近期查询过的域名结果暂存在本地缓存中。如果早先在未开启代理或网络异常时查询到了错误的解析结果，后续一段时间内应用直接读取旧缓存，就会出现「明明客户端已连接，却依然报 DNS 错误」的情况。
- 浏览器自带的安全 DNS（DoH）：现代主流浏览器往往默认集成了基于 HTTPS 的安全 DNS 功能。当浏览器自行向特定的远程服务器发起加密解析，而桌面独立应用仍在使用本地路由器分配的运营商 DNS 时，两者拿到的目标地址就会不一致，从而导致访问体验截然不同。遇到此类问题时，可参考连接故障排查中心中的 DNS 清理步骤进行处理。
环节二：应用对「系统代理」的遵从度不同
在 Windows 或 macOS 上开启客户端的「系统代理（System Proxy）」开关，本质上是向操作系统的注册表或网络偏好设置写入了一个本地监听地址（例如 127.0.0.1:7890），并礼貌地通知各个软件：「请把网络请求发往这个本地端口。」
然而，并非所有程序都会听从操作系统的这项通知：
- 严格遵循系统代理的应用：如 Edge、Chrome、Safari 等主流浏览器，在启动时会自动读取系统代理参数，将 HTTP 与 HTTPS 网页请求顺利交由客户端按规则分流。
- 拥有独立网络栈或忽略系统代理的应用：许多跨平台桌面软件、游戏客户端以及终端命令行工具，在开发时直接调用底层套接字（Socket）或采用 UDP 协议通信，完全不读取系统的 HTTP 代理设置。这就是为什么浏览器一切正常，而某些独立软件却如同断网一般。
- 解决方案：虚拟网卡（TUN 模式）：为了解决不遵循系统代理的应用分流问题，现代客户端（如 ClashParty 等）提供了 TUN 虚拟网卡模式。开启后，客户端会在系统底层创建一个虚拟网络接口，从 IP 层统一接管全机流量并交由分流规则处理。具体开启方式可查阅多平台客户端配置教程。
环节三：HTTPS 握手、路由路径与浏览器扩展干扰
即便两个应用都成功把请求交给了客户端，它们在实际传输过程中的表现仍可能受到以下因素影响：
- 浏览器扩展插件的覆盖效应：如果浏览器中曾安装过专门管理代理切换的扩展插件，该插件的优先级往往高于操作系统的系统代理。一旦插件指向了一个已经废弃的旧端口，就会出现「独立应用能联网，唯独该浏览器打不开网页」的反常现象，详细排查顺序可阅读网络连接显示正常但网页打不开逐层检查。
- HTTPS 证书校验与系统时间：现代网页与应用广泛采用 HTTPS/TLS 加密连接。在握手阶段，客户端与服务器会校验数字证书的有效期。若本地设备时间出现明显偏差，严格校验时间戳的应用就会立即中断连接。
日常保持稳定连接路径的实用建议
- 当仅需浏览网页与常规办公时，保持客户端「系统代理 + 规则模式（Rule）」即可兼顾轻量与稳定；
- 当需要使用不提供代理设置选项的桌面独立软件时，再按需开启客户端的「TUN 模式」；
- 切换网络环境或修改 DNS 设置后，养成重启浏览器或刷新本地 DNS 缓存的习惯，让所有应用恢复清晰的连接路径。