如何检查 NO_PROXY 规则是否让请求绕过了预期代理

NO_PROXY 列出无需经过代理的目标，因此规则命中时，请求会直接连接目标，通常不会产生错误提示。页面能打开并不能证明代理正常工作：应固定目标地址，并同时核对目标侧看到的出口 IP 和代理侧请求日志。

NO_PROXY 命中后，请求为什么会静默直连

环境变量 NO_PROXY（小写 no_proxy 同理）列出的是“不走代理”的目标。请求一旦命中，客户端就直接连接目标地址，代理侧完全看不到这次请求。

规则命中通常是客户端按配置执行的直连行为，因此业务请求仍可能成功。是否造成风险取决于应用预期路径和目标规则，不能仅凭请求成功或失败判断。

不同客户端为何会对同一条 NO_PROXY 规则得出不同结果

若测试对象使用 HTTP 代理，可对照HTTP 代理指南确认接入方式；若使用 SOCKS5，则参考SOCKS5 代理指南。具体规则仍应以客户端和版本文档为准。

同样的规则在不同客户端和版本中可能有不同含义。主机与子域的后缀匹配、前导点、逗号或空格分隔、大小写、端口、通配符和 CIDR 支持情况，都应以对应实现的文档和实测为准。还要确认客户端是否启用了环境代理支持；例如运行库若默认不读取代理环境变量，就不能据此判断 NO_PROXY 匹配失败。

所以规则不能靠“看起来对”来判断，只能针对实际使用的客户端逐条验证。同一份配置在不同语言栈里表现不同，是这类问题最常见的误报来源。

本地测试域名可以暴露 NO_PROXY 规则的边界差异

使用直连和代理两路均可达的受控目标，逐条改变规则并记录请求实际经过的路径。若测试目标部署在本机，需注明代理与目标的位置：远端代理访问 127.0.0.1 时指向的是代理所在主机，本机 hosts 设置也不一定会被远端代理使用。localhost 和 loopback 应单独测试，因为客户端可能对它们有专门的旁路处理。

• 测试记录字段（按实际客户端和版本填写）：按项目实际客户端填写 ｜ 环境代理启用方式：记录对应配置 ｜ NO_PROXY 规则：example.test ｜ 请求目标：example.test ｜ 对应版本的文档预期：查该版本文档 ｜ 实测路径/证据：客户端路由与目标记录
• 测试记录字段（按实际客户端和版本填写）：按项目实际客户端填写 ｜ 环境代理启用方式：记录对应配置 ｜ NO_PROXY 规则：example.test ｜ 请求目标：a.example.test ｜ 对应版本的文档预期：查该版本后缀语义 ｜ 实测路径/证据：客户端路由与目标记录
• 测试记录字段（按实际客户端和版本填写）：按项目实际客户端填写 ｜ 环境代理启用方式：记录对应配置 ｜ NO_PROXY 规则：.example.test ｜ 请求目标：example.test ｜ 对应版本的文档预期：查前导点语义 ｜ 实测路径/证据：客户端路由与目标记录
• 测试记录字段（按实际客户端和版本填写）：按项目实际客户端填写 ｜ 环境代理启用方式：记录对应配置 ｜ NO_PROXY 规则：example.test:8080 ｜ 请求目标：example.test:8080 ｜ 对应版本的文档预期：查端口匹配语义 ｜ 实测路径/证据：客户端路由与目标记录
• 测试记录字段（按实际客户端和版本填写）：按项目实际客户端填写 ｜ 环境代理启用方式：记录对应配置 ｜ NO_PROXY 规则：EXAMPLE.TEST ｜ 请求目标：example.test ｜ 对应版本的文档预期：查大小写语义 ｜ 实测路径/证据：客户端路由与目标记录
• 测试记录字段（按实际客户端和版本填写）：按项目实际客户端填写 ｜ 环境代理启用方式：记录对应配置 ｜ NO_PROXY 规则：10.0.0.0/8 ｜ 请求目标：10.1.2.3 ｜ 对应版本的文档预期：查 CIDR 支持情况 ｜ 实测路径/证据：客户端路由与目标记录

每个结果都应绑定客户端名称、版本和代理环境配置。固定出口有助于隔离变量，但不是所有测试的必要条件；使用动态出口时，可以按每次实际分配记录出口和目标侧来源地址，不应承诺无法控制的固定出口或持续时长。

此表是测试记录模板，不是所有客户端都适用的预期结果清单。按实际使用的客户端和版本填写，不预设 Requests、undici 或 cURL 的统一结果。使用 Node.js undici 等运行库时，确认项目是否显式启用了环境代理 Agent，再记录该版本的文档说明和实测结果。客户端升级或代理环境配置变化后，重新执行相关用例。

出口 IP 和代理日志如何证明请求经过了代理

请求成功不能证明流量经过代理。对受控目标发送带唯一用例 ID 的请求，并关联客户端连接记录、代理隧道记录和目标侧来源信息。普通 HTTPS CONNECT 隧道的代理日志通常只能提供连接目标（主机与端口）及连接级信息，不能要求它记录加密隧道中的 URL 路径；还应确认日志覆盖范围、采样、保留时间和读取权限。

若出口地址因共享 NAT 或共用出口无法区分，应补充客户端路由事件或受控代理到达计数。日志缺失时先核对覆盖和权限；证据不足就标记为“未确认”，不能仅靠增加样本下结论。

哪些配置最容易造成请求意外旁路

下面四种情况都不会报错，只能靠规则审查加出口 IP 反查发现。

localhost 和内网地址为何常被默认排除

客户端或运行库往往自带默认例外，localhost、127.0.0.1 和内网段常常被默认排除。这类默认值不在你的配置里，只能通过查客户端文档或实测确认。

环境变量的覆盖顺序会改变实际生效规则

HTTPS_PROXY、https_proxy、ALL_PROXY 与 NO_PROXY 的优先级由客户端实现决定，不一定只取决于变量加载顺序。测试时应清理冲突变量、逐项注入，并记录客户端实际采用的代理配置和目标匹配结果。

过宽的通配符和短后缀可能误排除业务域名

一个通配符或过短的域名后缀，可能把业务域名一起排除掉。写规则时用边界表逐条跑，别只看长得像不像。

系统代理与应用配置叠加时，旁路规则更难判断

系统代理与应用配置叠加时，两套规则各自生效，实际走了哪套要单独确认。测试时先关掉一层，再打开另一层，否则冲突时无法判断是谁放行的。

发现绕过之后，先改规则，再补一条回归用例，把这次命中的目标固定进测试集，避免下一次同类请求又被悄悄放行。

FAQ

为什么 NO_PROXY 命中后什么提示都没有？

因为 NO_PROXY 用于指定不经过代理的目标，命中时通常会按配置直连。要确认实际行为，应结合客户端路由记录、受控目标的来源信息和代理连接日志；单凭某一项外部证据可能不足。固定出口可用于隔离变量，动态出口则记录每次实际分配结果。

NO_PROXY 里该写域名还是 IP 网段？

取决于客户端的支持能力：有的只做域名后缀匹配，有的支持 CIDR。先确认实现，再写规则；否则写了可能不生效，或者生效范围比预期大得多。

怎么证明某次请求确实没走代理？

使用带用例 ID 的受控请求，并关联客户端路由事件、目标侧来源记录和代理连接日志。对 HTTPS 核对连接目标与时间窗；先确认日志覆盖和权限。若客户端与代理记录无法区分直连和代理路径，应标记证据不足，而不是仅凭“无代理日志”断定。

判断 NO_PROXY 是否造成旁路，关键是将规则命中结果与实际网络路径对应起来。客户端配置方式应查阅对应版本的官方文档；项目内原列出的 Linux/cURL 和 Python requests 帮助地址目前返回资源不存在，因此不保留这些失效链接。Node.js 页面尚未核实，本稿也暂不加入。