网关访问本机上游却绕进代理：怎样验证NO_PROXY与环境继承

网关调用本机上游却经过了工作代理，可能是服务进程继承了HTTP_PROXY。本文只使用127.0.0.1上的假代理和假目标，用两边计数确认实际路由。此次已在Python 3.12.4、HTTPX 0.28.1下执行，未访问公网，也没有使用真实代理凭证。

用两个不同响应标记替代猜测

运行器分别启动target和proxy回环服务，随机分配端口，两者只返回自己的名称并累计命中。第一轮设置HTTP_PROXY且不设置排除，目标URL虽然是回环地址，HTTPX仍访问假代理，响应标记为proxy。第二轮加入NO_PROXY为127.0.0.1，标记变成target。第三轮去掉排除但显式trust_env=False，也直接命中target。

最终假代理命中一次，假目标命中两次。这个双端计数比单看客户端200更有区分度，因为代理和目标都能返回200。测试输出只保存合成地址的路由结论与库版本，没有打印原来进程环境里的值。临时修改的变量在finally中恢复，两个服务结束后关闭。

环境继承要在服务进程里核对

交互终端里设置正确，不代表系统服务、容器或进程管理器启动的网关也继承同样环境。可先只列相关变量名称和是否设置，确认来源，再用假值复现。不要为了排查一个服务就全局删除用户工作代理，也不要将真实带密码代理URL写入日志。

HTTPX官方说明默认读取环境变量，trust_env=False可关闭这种读取。不同库对NO_PROXY的主机名、端口和网段语义可能不同。本文只实际验证字面127.0.0.1这一项，不保证localhost、IPv6或CIDR在所有库里有相同匹配。若生产使用另一个HTTP库，必须按它的版本增加独立向量，而不是沿用本次答案。

根据边界选择排除还是忽略环境

如果服务既需要访问本地上游又需要通过代理出网，合理的排除规则可以保留出网路径；若该服务所有路由都应由代码显式控制，可考虑关闭环境继承，并为必要代理单独配置。具体选择取决于部署需求，不能把trust_env=False当成通用网络修复按钮，因为它也影响HTTPX识别的其他环境设置。

本地通过只证明这一版本在三种条件下的路由选择，不证明生产网络可达、代理权限正确或真实模型响应成功。集成时保存目标主机形式、HTTP库版本、服务环境来源和两端匿名计数；若更换了域名或启动方式，再跑一遍受控实验。让路径由可观察标记证明，能避免“请求成功所以一定没走代理”的错误判断。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C024。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

代理实验需本地已安装httpx，仅启动两个回环假服务，并在结束时恢复本进程的环境变量。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文讨论国内网络连接优化；本文只定位服务进程继承代理环境导致本机流量改道，输出代理和目标两边的命中计数。