NO_PROXY 在 curl、.NET 与容器之间的兼容性
用一小组有代表性的目标，把共享的直连策略转成各客户端专属的配置。
团队把一条绕过字符串放进共享的环境文件。curl 走直连，另一个应用使用代理，容器的行为又不一样。共享文件分发的是同样的字符，而不是同一个解析器。
真正持久的是策略：哪些目标应当直连，在什么条件下直连？把它与每个程序所需的那条字符串分开。
先写下预期的路由
使用有代表性的地址，包括边界情况，而不只是容易成功的例子：
| 目标形态 | 向策略负责人提出的问题 |
|---|---|
| 父域名 | 是整体绕过，还是只绕过其子域名？ |
| 子域名 | 它是否继承同一条路由？ |
| 字面写出的私有 IP | 该地址能否从此客户端直接访问？ |
| 同一服务的主机名形式 | 按名称和按地址的请求是否应当一致？ |
| 同一服务的其他端口 | 例外覆盖的是整台主机还是单个监听端口？ |
然后识别消费者：拉取镜像的守护进程、容器内的程序、某种语言的 HTTP 库以及交互式浏览器都可能是独立条目。Docker 客户端的代理配置可以填充容器的环境变量，而无需让容器内的每个客户端都实现相同的匹配规则。
翻译而不是盲目照抄
一个有据可查的真实差异例子是父域名的边界。curl 的域名排除覆盖所写域名及其匹配的子域名。.NET 的环境策略则区分裸名与带前导点的子域形式。一条“总是加前导点”的通用规则无法可靠地表达这两种策略。
IP 段支持同样取决于消费者及其版本。装有新版独立 curl 的机器仍可能运行链接旧版 libcurl 的应用程序，或使用完全不同库的客户端。操作系统发行版并不等于完整的客户端清单。
对每个消费者，记录其支持的配置接口以及预期路由的最小表达。一份简短的显式主机列表，可能优于无人能解释其含义的巧妙模式。
把配置证据与连接证据分开
解析后的设置或路由决策 API 可以显示程序选择了什么。请求结果则显示该路由是否可用。在 .NET 中，当默认代理就是正在使用的策略时，HttpClient.DefaultProxy.IsBypassed 提供配置侧的校验。不要仅因为请求超时，就把无法访问的直连服务诊断为绕过解析器故障。
在更新客户端或基础镜像时保留边界目标。它们能让未来的兼容性变化显现出来，而不必让整个团队重新发现文件里为什么有两条看起来相似的域名条目。