browser works but application fails：浏览器能用但应用不能连接
browser works but application fails严重程度 Medium浏览器正常说明链路本身是通的，问题在于那个应用的流量没有走上同一条路。最可能是该应用不读取系统代理，或分流规则没覆盖它的目标域名；第一步是确认该应用有没有自己的代理设置项。
结论
这个症状自带一条免费的好消息：链路是通的。浏览器能正常访问，说明从你的设备到代理到出口的整条路都在工作。失败的应用只是没走上这条路——它的流量要么直连了（而直连到不了目标），要么走进了错误的分流分支。排查的全部工作就是回答一个问题：那个应用的流量到底走了哪里？
适用环境
- 全部平台
- 高发应用类型：命令行工具（git、包管理器）、桌面客户端（IM、游戏、同步盘）、开发工具
一分钟快速判断
- 查应用自己的代理设置：很多应用有独立代理配置（IM 工具、下载器、开发工具几乎都有）。它里面若写着一个过期端口，系统代理再正确也救不了它；
- 临时切全局模式：把代理客户端从"规则/分流"切到"全局"，应用恢复 → 分流规则漏了它的目标域名；仍失败 → 该应用压根没把流量交给代理；
- 区分应用类型：命令行工具默认不读系统代理（它们读环境变量），这是设计而非故障，跳到对应小节。
这条错误代表什么
"系统代理"并不是一个强制机制，而是一个建议：操作系统把代理地址放在一个约定位置，应用自愿决定是否遵循。浏览器最守规矩；很多桌面应用选择性遵循；命令行工具普遍无视它而信仰环境变量；还有些应用使用固定 IP 直连或私有协议，代理规则按域名匹配时根本碰不到它们。所以"浏览器通、应用不通"不是矛盾，而是同一台设备上并存着好几套流量路径。
ConnProof 如何判断
先取证应用的目标是否真的需要代理：
connproof diagnose 应用的目标域名在客户端关闭状态下检测：直连能通 → 应用失败另有原因（应用自身故障、账号问题）；直连不通 → 确认该目标必须走代理，问题就在"应用没走代理"。再运行 connproof doctor 拿到系统代理指向与端口监听证据，为下面的配置核对提供基准。
最常见原因
- 应用不读取系统代理：命令行工具、部分老旧桌面应用；
- 分流规则未覆盖：应用的目标域名/IP 不在代理规则里，被引导直连；
- 应用内置代理配置过期：应用里写死的端口早已不是客户端当前监听的端口；
- 应用走 UDP 或私有协议：系统代理只覆盖 TCP 的 HTTP(S) 流量，游戏、语音类应用的 UDP 流量完全在其外（需要 TUN 模式才能接管）；
- 应用使用固定 IP：按域名写的分流规则匹配不到纯 IP 连接。
Windows / macOS 排查步骤
- 应用设置里找代理项：有 → 核对端口与
connproof doctor显示的监听端口一致； - 命令行工具：为当前会话设置环境变量后重试（PowerShell：
$env:HTTPS_PROXY="http://127.0.0.1:端口"；bash/zsh：export https_proxy=http://127.0.0.1:端口）。恢复即确诊，按各工具的配置文件做持久化（git 有http.proxy，npm 有proxy配置项等）； - 分流场景：把应用目标域名加进代理规则，或用客户端的"连接记录"面板观察该应用的连接被判到了哪个分支（DIRECT/代理/REJECT）——这是最直观的证据；
- UDP/固定 IP 场景：启用客户端的 TUN/增强模式，让接管发生在网络层而不是应用层。
手机端排查步骤
- 手机的 VPN 模式本质就是 TUN——理论上接管所有应用。仍有应用连不上时，检查客户端的"分应用代理"（per-app proxy）名单是否把它排除了；
- 部分安卓厂商系统会对省电名单外的应用限制后台网络，把失败应用加入"不受限制"名单；
- 应用有"私有 DNS/自选 DNS"设置的，检查它是否绕过了代理的解析路径。
如何区分本地问题和节点问题
这条错误里链路已被浏览器证明是通的，剩下的分歧都在本地配置与应用行为：
| 证据 | 结论 |
|---|---|
| 全局模式下恢复 | 分流规则缺口 |
| 设环境变量后恢复 | 命令行工具正常行为，持久化配置即可 |
| 应用内代理端口与实际不符 | 应用配置过期 |
| TUN 模式下恢复 | 应用流量类型（UDP/固定 IP）超出系统代理范围 |
| 任何模式都失败且直连也失败 | 应用或其服务端自身故障，与代理无关 |
一个容易踩的陷阱：环境变量的作用域
给命令行工具设置代理环境变量时，注意它只对当前这个终端会话生效：新开的终端、图形界面启动的程序、计划任务都读不到它。很多"我明明设置了还是不行"的困惑源于此——你在终端 A 里 export 了变量，却在终端 B 或 IDE 内置终端里运行工具。持久化的正确位置是 shell 配置文件（~/.zshrc、~/.bashrc）或各工具自己的配置项；而写进 shell 配置文件后也要意识到它成了新的"配置残留"候选——客户端换端口时记得同步更新，否则几个月后你会在本站的 proxy connection refused 页面再见到自己。
仍未解决时收集什么信息
- ConnProof 错误码（CLIENT-003）与 diagnose/doctor 脱敏报告；
- 失败应用的名称与版本、它的目标域名；
- 全局模式与 TUN 模式的对照结果；
- 客户端连接记录里该应用连接的分流判定截图（自行确认无敏感信息）。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof diagnose 应用的目标域名 --format markdown --output diag.md修复后在客户端连接记录中应能看到该应用的连接走向预期分支。
相关文档
更新记录
- 2026-07-28：规则 v1 发布，梳理五类"应用流量不走代理"的路径差异。