代理客户端显示“已连接”，但目标网站仍看到本地出口，或者只有部分应用换了 IP，通常不是一个单点故障。连接成功只说明客户端与代理服务器建立了通道，不代表系统、浏览器、命令行工具和后台进程都会自动使用这条通道。排查时要先确认哪些请求走代理，再沿着系统代理范围、应用绕过规则、IPv6、DNS 和分流策略逐层定位。
最稳妥的做法是准备三类测试：浏览器访问检测页、命令行发起同一目标请求、真实业务应用执行一个低风险小样本。三类请求都记录 IPv4、IPv6、DNS、目标地址、时间和实际出口。只有这样，才能判断是全局未生效、单个应用绕过，还是某一种协议没有进入代理。
先用这张表确认“没走代理”发生在哪一层
| 检查对象 | 记录字段 | 通过条件 | 失败信号 |
|---|---|---|---|
| 浏览器请求 | IPv4、IPv6、出口地区、检测时间 | 出口与代理线路一致 | 仍显示本地出口或两次结果不同 |
| 命令行请求 | 工具、协议、代理参数、目标地址 | 显式代理与系统代理结果一致 | 显式设置生效，系统设置不生效 |
| 真实应用 | 应用名、版本、代理模式、绕过列表 | 应用出口与测试页一致 | 只有该应用继续走本地网络 |
| IPv6 路径 | 是否启用、出口地址、目标站支持情况 | IPv4 与 IPv6 都符合预期 | IPv4 走代理，IPv6 仍走本地 |
| DNS 路径 | 本地或远程解析、解析器、目标节点 | 解析策略与代理模式一致 | 请求走代理但解析仍从本地发出 |
1. 先区分连接成功和出口生效
第一步不要只看客户端状态灯。分别检测浏览器、命令行和真实应用的实际出口 IP，并保存时间与协议。若三者都显示本地出口，优先检查代理地址、端口、认证和系统代理是否真正保存；可以按代理连接超时与配置检查顺序重新核对基础字段。
若显式指定代理的命令行请求可以换出口，但浏览器或应用不行，说明代理服务器本身大概率可用，问题更可能在系统接管范围或应用自己的网络设置。此时不要频繁更换线路，以免把配置问题和线路质量混在一起。
2. 检查系统代理覆盖范围
系统代理通常只影响遵循系统网络设置的程序。有些应用自带代理配置，有些只读取启动时的设置，还有些后台服务完全忽略系统代理。修改设置后要重新启动测试应用，并确认自动配置脚本、手动代理和“对本地地址不使用代理”等选项没有互相覆盖。
如果应用要求明确选择协议，要先确认 HTTP、HTTPS 和 SOCKS5 是否匹配。协议选错可能出现“连接成功但目标请求未进入通道”的假象。可以对照代理协议选择检查表，分别测试网页访问、加密连接和需要远程解析的请求。
3. 查找应用绕过列表和分流规则
绕过列表、直连域名、私有地址排除项和按进程分流，是最常见的“部分流量没走代理”原因。检查是否存在通配符、旧域名、局域网段或默认直连规则。不要一次删除全部规则；先复制当前配置，再对一个测试域名做最小改动，确认出口变化后再扩大范围。
如果只有部分网站异常，要把目标域名、跳转域名、状态码和最终出口一起记录。目标网站可能调用多个域名，其中主页面走代理，静态资源或登录接口却命中直连规则。可参考同一代理下网站表现不一致的排查表，按域名和访问路径拆分测试。
4. 单独验证 IPv4 和 IPv6
很多代理配置只接管 IPv4，而系统仍优先通过本地 IPv6 访问支持双栈的目标站。这样会出现部分检测页显示代理出口，另一些检测页显示本地地址。复测时必须把 IPv4 和 IPv6 结果分开保存，并确认代理工具是否明确支持 IPv6 转发。
若 IPv6 未被代理接管，不要用隐藏检测结果代替修复。应根据业务需要选择支持相应协议的线路、调整系统路由，或在可控测试环境中暂时停用未接管的协议，再确认业务应用没有因此失去必要连接。任何改动都要保留回滚记录。
5. 确认 DNS 是否跟随代理
即使网页流量通过代理，DNS 查询仍可能从本地网络发出。对于 SOCKS5 等场景，还要区分本地解析和远程解析。建议同时记录解析器、解析位置、目标节点和实际出口，沿用DNS 本地与远程解析检查路径判断请求链是否一致。
DNS 结果异常不一定表示全部流量绕过，但会让目标节点选择、地区内容和故障定位变得混乱。修正后应清理系统与应用的 DNS 缓存，再用相同目标、相同时间窗口复测，避免把旧缓存当成新配置结果。
6. 用对照测试确认修复，而不是只看一次 IP
修复后的验证至少包含两轮：第一轮使用干净浏览器和显式代理请求，第二轮使用真实应用的小样本任务。每轮都保存配置版本、IPv4、IPv6、DNS、目标域名、状态码、延迟和实际出口。可以在代理测试记录模板中增加“应用名称”“是否命中分流”“IPv6 出口”三列。
| 复测结果 | 判断 | 下一步 |
|---|---|---|
| 所有测试出口一致 | 代理接管范围符合预期 | 继续低流量观察 |
| 显式代理生效，系统代理不生效 | 系统设置或自动配置冲突 | 核对保存状态与覆盖规则 |
| 浏览器生效，单个应用不生效 | 应用自带网络栈或绕过规则 | 检查应用级代理和进程分流 |
| IPv4 生效，IPv6 不生效 | 协议接管不完整 | 修正双栈支持或路由策略 |
| 出口正确，DNS 仍走本地 | 解析路径未跟随代理 | 调整远程解析并清理缓存 |
7. 保留停止条件和回滚点
若修改分流或路由后出现大量连接失败、内部服务不可达、IPv6 业务中断、认证错误增加或出口持续漂移，应立即回滚到已知可用配置，不要继续在真实任务上试错。线路基础状态也要先确认，再讨论应用接管范围。
需要重新选择线路时，可以从住宅代理线路做低流量验证，但不要把换线路当作第一步。只要显式代理请求能够正常更换出口，优先修正系统设置、应用配置、IPv6 和 DNS；只有线路本身在多个独立测试中都失败，才进入更换或隔离流程。
结论：用三类请求锁定绕行位置
代理连接成功但流量没走代理，核心是先回答“哪一类请求绕行”。浏览器、命令行和真实应用三组对照，可以快速区分代理服务器故障、系统代理未覆盖、应用绕过、IPv6 直连和 DNS 路径不一致。
把出口、协议、应用、分流、IPv6 和 DNS 放进同一份复测记录，并为每次修改保留回滚点，才能让修复结果可验证。不要以客户端状态灯或单次 IP 检测作为上线依据。