为什么你的企业代理会尝试解析 Compose 服务名

HTTP 客户端可能在使用 Docker 的服务名解析之前，就把内部服务请求发给了已配置的代理。为合适的客户端添加有意的绕过规则。

应用通过企业代理访问互联网，但 http://catalog:8080/ 失败，代理无法解析 “catalog”。该请求可能从未使用过 Docker 的内部 DNS。

HTTP 客户端可能在建立直连之前就选定代理。此时外部代理收到的名字，其含义只存在于 Compose 网络内部。

  1. 在请求中使用主机名。 Compose 服务可以在相应网络上通过服务名被发现。请把 catalog 加入使用方客户端支持的绕过配置，而不是硬编码可能变化的容器 IP。
  2. 保留现有例外。 对于能感知环境的客户端，把相关条目并入组织的列表：
NO_PROXY=localhost,127.0.0.1,catalog
no_proxy=localhost,127.0.0.1,catalog

检查镜像中实际使用的库或可执行文件如何处理大小写、版本和匹配语法。并不存在通用的 NO_PROXY 解析器。小镜像里名为 wget 的程序未必表现得像 GNU Wget。

当请求选择直连路由后，检查调用方与服务共享的网络、正在监听的服务以及容器端口。已发布的宿主机端口是另一个端点。绕过无法补上缺失的网络接入，正如重建网络也无法让外部代理认识私有的 Compose 名称。

保持预期的划分：内部请求走内部路径；外部请求保留获批的代理。全局关闭代理可能掩盖这一处故障，同时移除下一次外部请求所需的路径。

相关文章