购买机场后，订阅链接的安全性往往被忽略。本文从 链接暴露位置、异常用量、订阅失效和服务跑路 等情况出发，说明如何快速判断风险，并在 Clash 中安全更换订阅、撤销旧链接和恢复正常使用。 一、为什么 Docker 里配置了代理，拉镜像仍然超时 很多人第一次处理 Docker 拉取镜像超时 时，会在容器里执行 export HTTP_PROXY=... ，然后发现 docker pull 依旧卡在连接或 TLS 握手阶段。这里最容易混淆的是：执行 docker pull 的主体通常不是业务容器，而是宿主机上的 Docker Engine 。Docker CLI 只是向守护进程发送请求，真正访问 Docker Hub、镜像仓库和认证服务的是 dockerd 进程。因此，容器内的环境变量并不能自动改变 Docker Engine 的出口。 同样，宿主机浏览器能够通过 Clash 打开网页，也不能证明 Docker 网络已经代理。浏览器可能使用了系统代理或浏览器扩展，而 Docker Engine、容器内的 apt 、 npm 、 git 和应用自身的 HTTP 客户端，都可能采用完全不同的网络路径。尤其是在 Linux 服务器上，Clash 以用户态进程运行，Docker bridge 网络又经过独立的网桥、NAT 与 DNS 转发，链路中任何一层没有对齐，最终都会表现为「Docker 不能联网」。 本文讨论的是以 Clash 或 Mihomo TUN 模式 为核心的透明代理方案。它的目标不是把代理地址硬编码进每一个容器，而是让宿主机上的出站流量经过 TUN 虚拟网卡进入 Clash，再由规则组选择代理或直连。这样既能覆盖不支持代理变量的程序，也能减少为每个 Compose 服务重复配置代理的维护成本。 二、先画清数据流：宿主机、Docker bridge 与 TUN 的关系 在默认 Docker 网络中，容器通常位于一个独立的 bridge 子网，例如 172.17.0.0/16 。容器发出的数据包先到达虚拟以太网设备，再经 Docker 网桥转发到宿主机，最后由宿主机上的 NAT 规则转换为外部连接。若宿主机启用了 Clash TUN，理论上这些出站连接还要被路由到 TUN 设备，由 Mihomo 接管、解析目标地址并转发到代理节点。 问题在于，TUN 并不是一条自动吸收所有流量的「魔法网线」。它依赖路由表、自动路由、网卡排除列表以及内核转发状态。若 Docker bridge 网段被错误排除，容器流量可能绕过 TUN 直接出网；若所有流量都被送入 TUN，却没有排除 Clash 节点自身的连接，则可能形成回环：Clash 连接代理服务器，代理服务器连接又被 Clash 重新捕获，最终出现节点握手失败或 CPU 持续升高。 建议先用下面的简化模型定位故障位置： Docker Engine 路径 ：宿主机上的 docker pull 是否能访问认证服务与 Registry。 容器路径 ：容器内的 DNS、HTTPS 和应用连接是否经过宿主机正确转发。 Clash 路径 ：Mihomo 是否看到请求，规则是否匹配到预期策略组。 节点路径 ：代理节点是否能完成 DNS、TCP、TLS 或长连接建立。 这四条路径要分开测试。不要一上来就修改几十条规则，也不要把「容器访问失败」直接等同于「节点速度不够」。如果 Clash 连接面板里完全没有对应域名，问题发生在 TUN、路由或 Docker 出口之前；如果请求已经进入 Clash 但被判定为 DIRECT ，则重点应转向规则与 DNS。 排查原则 ：先确认请求有没有进入 Clash，再确认 DNS 返回了什么，最后才比较不同节点的延迟。顺序颠倒时，换节点往往只能暂时掩盖路由问题。 三、Mihomo TUN 基线：透明代理必须先配置完整 不同 Clash 客户端的界面名称可能不同，但底层通常都围绕 tun 、 auto-route 、 auto-detect-interface 和 DNS 增强模式展开。Docker 服务器上更适合直接检查 YAML 或合并后的配置，而在 Clash Verge Rev 等桌面客户端中，则可以先打开 TUN，再通过连接记录验证结果。 下面是一段用于理解字段关系的示意配置，不能直接替代你的订阅文件。实际使用时，应按照当前 Mihomo 版本支持的字段和客户端生成方式调整： stack: mixed 通常比只固定某一种协议栈更适合需要兼容不同应用的环境； auto-route 负责协助写入路由； auto-detect-interface 让内核识别当前主要出口网卡。对于生产服务器， strict-route 能减少部分流量绕过 TUN 的情况，但也会放大错误路由的影响，启用前必须确认 SSH 管理链路和宿主机局域网网段不会被误代理。 Docker 常用的 bridge 网段、宿主机局域网网段、云厂商元数据地址以及代理节点连接，都应根据实际环境设计排除策略。不要机械复制别人的 route-exclude-address 。家庭网络、云服务器和公司内网的网段可能完全不同，错误排除会造成「浏览器正常、容器不通」或「公网正常、内部服务失联」。修改后应保留旧配置，并通过控制台或带外管理通道确认服务器仍可登录。 四、DNS 调优：Docker 超时经常不是代理节点慢 Docker 透明代理中最常见的隐性问题是 DNS。容器默认可能使用 Docker 内置 DNS 转发器，宿主机则可能使用 systemd-resolved、运营商 DNS、公司 DNS 或云平台提供的解析服务。即使 TCP 流量已经进入 Clash，域名解析仍可能在代理之外完成，导致 Docker Hub 返回不可达地址、解析结果被污染，或者 IPv6 地址优先而实际链路并不支持 IPv6。 fake-ip 模式会为域名分配保留地址，再由 Clash 根据域名映射回真实目标，适合需要保持域名规则匹配的透明代理环境。但部分内网服务、硬编码 IP 的程序、依赖真实 DNS 响应的认证组件，可能与 fake-ip 不兼容。遇到容器访问数据库、服务发现或内网域名异常时，不要只看公网访问结果，应为内网域名设置 fake-ip-filter 或使用合理的 nameserver-policy。 可以按「域名类别」设计解析策略，而不是把所有请求都交给同一个 DNS： 如果 Dockerfile 中执行 apt-get update 时失败，可以先在容器内查看 /etc/resolv.conf ，再分别测试域名解析与 HTTPS 连接。 getent hosts 成功只说明拿到了地址，不代表该地址能够建立 TLS；反过来，某个 DNS 工具不存在也不能直接证明 DNS 失效。将「解析失败」「连接超时」「证书错误」分开记录，排障效率会高很多。 五、Docker Engine 与容器应用：两套代理配置不要混用

若核心问题是 docker pull 、 docker push 或私有 Registry 访问，优先为 Docker Engine 配置代理，而不是只给 Compose 服务添加环境变量。Linux 上通常通过 systemd drop-in 为 dockerd 设置 HTTP_PROXY 、 HTTPS_PROXY 与 NO_PROXY ，代理地址应指向宿主机可访问的 HTTP 或 mixed 入站端口。配置完成后需要重新加载 systemd、重启 Docker 服务，并用 docker info 或日志确认代理设置已被读取。 示意配置如下，端口和地址请替换为你的实际值： 这里的 NO_PROXY 很重要。内网 Registry、Docker 网桥、宿主机管理地址和服务发现域名通常不应经过公网代理。若使用远程 Docker Engine， 127.0.0.1 指的是服务器自身，而不是执行 CLI 的个人电脑；这是远程部署中非常常见的地址误判。 容器内应用则是另一层。Compose 中的 HTTP_PROXY 、 HTTPS_PROXY 只影响读取这些变量的程序，不能强制所有二进制遵守代理。某些 Go、Java、Python 应用会读取环境变量，某些程序则需要专用参数；如果采用 TUN 透明代理，应用本身可以不配置代理，但仍应维护正确的 NO_PROXY ，避免把数据库、容器名和健康检查请求送到外部节点。 生产环境不建议把带认证信息的代理 URL 直接写进公开 Compose 文件。可以使用 systemd 环境文件、Docker secrets、CI/CD 的受保护变量或权限受限的 override 文件，并限制日志输出，避免 token、用户名和密码被打印到构建记录中。 六、路由、转发与防火墙：透明代理能否覆盖容器的关键 当 TUN 已开启但容器请求仍未出现在连接面板时，应检查宿主机是否允许 IPv4 转发，以及 Docker 创建的网桥和 NAT 规则是否仍然存在。不要看到一条规则就认为整个链路正确：iptables、nftables、Docker 自己的 DOCKER 链，以及防火墙管理工具可能同时参与转发。系统升级或切换防火墙后，规则顺序变化就可能让 Docker 流量提前走默认出口。 排查时可以先记录三类信息：容器默认网关、宿主机到外网的路由、Clash TUN 设备上的路由。执行 ip route 、 ip addr 和 Docker 网络查看命令，重点确认默认路由没有被重复覆盖，bridge 网段没有与公司 VPN 或云厂商 VPC 冲突。若容器能访问宿主机端口，却不能访问公网，说明容器到宿主机的局部网络可能正常，故障更可能位于转发、NAT、TUN 捕获或 DNS。 SSH 是服务器排障的生命线。修改 TUN 的自动路由、严格路由或防火墙规则前，准备第二个 SSH 会话、云控制台或带外终端；先在测试服务器验证，再推广到生产节点。对于需要长期运行的环境，还应记录 Clash 进程重启后的行为：TUN 设备是否自动创建、默认路由是否恢复、Docker 容器是否需要重启，以及节点切换时已有连接是否会中断。 不要在远程生产机上一次性执行「清空全部路由」或「重置全部防火墙规则」。透明代理配置错误可能直接切断 SSH、监控和内部服务访问。任何涉及默认路由与转发链的改动，都应先准备回滚命令和带外登录方式。 七、从现象到结论：一套可复用的 Docker 透明代理排障流程 建议把测试拆成宿主机、Docker Engine、临时容器和业务容器四个层级，每次只改变一个变量。这样即使问题没有立刻解决，也能知道是哪一层发生了变化。 在宿主机使用 curl 测试目标 Registry、认证域名和一个普通 HTTPS 站点，记录解析地址、HTTP 状态和耗时。 打开 Clash 或 Mihomo 连接面板，确认测试期间出现了对应域名，并记录命中的规则、策略组和最终出口。 执行 docker pull ，单独观察 Docker Engine 的日志与 Clash 连接记录，不要用业务容器结果替代 Engine 测试。 启动一个临时容器，分别测试 DNS、HTTPS、宿主机网关和内网服务，确认是解析问题还是 TCP 转发问题。 检查 TUN 的路由、Docker bridge 网段、IPv4 转发与防火墙链，排除流量绕行或回环。 最后再调整 DNS 模式、nameserver-policy、规则组和节点；每次修改后保留一组前后对比日志。 例如，若宿主机 curl 能通、 docker pull 失败，但 Clash 没有任何 Registry 连接记录，应先查 dockerd 是否使用了错误的代理地址，或者 Docker Engine 是否运行在另一台主机。若 docker pull 能通而容器内 npm install 失败，则重点查看容器 DNS、应用是否读取代理变量，以及 TUN 是否覆盖 Docker bridge 流量。若域名解析成功但 TLS 超时，才有必要进一步比较 MTU、IPv6、节点出口和中间防火墙。 生产环境还应加入可观测性：定期记录镜像仓库认证、镜像拉取、DNS 查询和代理进程重启事件；为 Clash、Docker Engine 与宿主机设置独立日志保留周期。不要只保存「失败」二字，至少记录时间、目标域名、容器名、策略组和错误类型。相同的超时如果每次都发生在 DNS 阶段，与随机发生在 TLS 阶段，处理方向完全不同。 八、上线前检查清单：让配置可维护，而不是只在今天能用 完成配置后，先把关键参数整理成一张小表：TUN 是否启用、使用哪种协议栈、Docker bridge 网段是什么、Docker Engine 代理端口是什么、哪些地址必须 NO_PROXY 、DNS 使用 redir-host 还是 fake-ip、内网域名由哪台 DNS 解析。日后更换服务器、机场或 Clash 客户端时，可以逐项迁移，而不是重新猜测每个开关的含义。 订阅更新和内核升级也应纳入变更流程。Mihomo 版本变化可能影响 TUN 栈、DNS 行为或字段兼容性；订阅服务商调整规则后，也可能让 Registry 域名从代理组变成直连。更新前导出当前生效配置与路由信息，更新后先做宿主机、Engine、临时容器三项回归测试，再恢复大规模构建任务。对于 CI 服务器，最好准备一个不依赖代理的内网镜像缓存，避免公网出口短暂波动时整个流水线停摆。 与只在每个容器里写代理变量的通用方案相比，逐服务配置更直观，却容易漏掉新容器、构建阶段和第三方二进制；Docker Desktop 的图形代理设置也较方便，但在远程 Linux、复杂 DNS 或多网卡服务器上可控性有限。Clash/Mihomo TUN 方案需要理解路由、DNS 和防火墙，前期门槛更高，却能在统一入口观察流量、按域名分流，并覆盖不支持代理变量的程序；如果你希望把这些能力稳定落地， 立即免费下载 Clash，开启流畅上网新体验 ，再按照本文的分层方法逐步验证即可。 集中管理订阅，减少泄露与误配置 使用 Clash 管理配置来源、更新周期和连接日志，在更换机场订阅后快速完成迁移与验证。 用 Clash 管理新配置，减少旧链接残留。