Docker 容器走宿主机 Clash：HTTP 代理环境变量与网关两种配置实测（2026）

1. 场景与目标：为什么优先用宿主机 Clash

本地开发时，镜像里再跑一个内核或图形客户端，往往带来重复配置、订阅双份维护、日志分散等问题。若宿主机上的 Clash已经按你的习惯写好了规则与策略组，把容器出站接到同一入口，规则仍然由宿主机那份 YAML 决定，容器侧只负责「把 TCP 连接交给谁」。这与站内专门讲整机安装与 systemd 自启的教程是互补关系：那边解决「宿主机进程如何稳定拉起内核」，本文解决「同一台机器上的 Docker子网如何触达该内核的入站端口」。若你尚未在 Linux 上完成基础安装，可先对照 Ubuntu 与 systemd 安装篇把本机服务跑通，再回到容器侧接线。

用户真实搜索意图里常见表述是「docker 代理」「容器走 clash」——落地时首先要分清：应用层显式代理（读环境变量）与网络层默认路由（整段流量从某个网关出去）不是同一套机制。前者对 HTTP/HTTPS生态工具链最友好；后者更适合你已经理解 Linux 路由、且准备在宿主机侧做透明转发或 TUN 抓全量的进阶场景。下面两节分别展开。

2. 宿主机前置：监听地址、mixed-port 与 allow-lan

容器要连宿主机上的代理端口，前提是：监听地址不能仅限 127.0.0.1，否则来自 bridge 网络的数据包会被操作系统直接拒在门外。常见做法是把 HTTP 或 mixed 入站绑定到 0.0.0.0，并在配置里打开 allow-lan（或等价选项），让局域网与 Docker 网桥网段可以访问。具体键名随内核与发行版略有差异，请以你所用的 mihomo / Clash Meta文档为准；原则是「本机回环」与「对 docker0 可见」要分开想，不要假设默认配置已经对容器开放。

mixed-port的含义是在同一端口上同时接受 HTTP 代理与 SOCKS 类握手（视实现而定）。给容器配 HTTP_PROXY=http://<host>:<port>时，端口应与你 YAML 里声明的 mixed 或独立 port一致。若你拆成了单独的 HTTP 端口与 SOCKS 端口，则环境变量里用 HTTP 那一个即可，不要把 SOCKS 端口误填进只支持 HTTP _CONNECT 的工具里。订阅与基础连通若仍有问题，可先过一遍 订阅导入教程，确认宿主机侧日志干净，再测容器。

3. 方案一：HTTP_PROXY / HTTPS_PROXY / ALL_PROXY 与宿主机地址

这是最贴近「开发者日常」的路径：显式代理。绝大多数语言生态里的 HTTP 客户端会读 HTTP_PROXY、HTTPS_PROXY，不少还会认 ALL_PROXY与 NO_PROXY。在 Docker Desktop（macOS / Windows）上，容器内访问宿主机常用特殊主机名 host.docker.internal；在较新的 Docker Engine 上也可以通过 extra_hosts注入同名解析到 host-gateway，以减少平台差异。Linux 原生环境若未提供该别名，可直接填 docker0 网桥的网关地址（常见为 172.17.0.1，以你机器 ip addr show docker0为准），或自定义 bridge 的网关 IP。

一条最小可读的 docker run示例（端口请改成你的 mixed-port）：

# Example: proxy HTTP/HTTPS from container to host Clash mixed port
docker run --rm -it \
  -e HTTP_PROXY=http://host.docker.internal:7890 \
  -e HTTPS_PROXY=http://host.docker.internal:7890 \
  -e NO_PROXY=localhost,127.0.0.1,.internal \
  curlimages/curl curl -I https://www.example.com

实测时建议先在容器里 curl -v看握手是否走到代理、再在宿主机 Clash连接日志里核对目标域名与策略组。若只看到直连而未见预期节点，多半是环境变量未传入该进程、或该工具不使用标准代理变量（例如部分静态编译的二进制）。

4. Compose、BuildKit 与 CI 里怎么写才稳

docker compose可以把代理变量写在 environment或 .env里，注意build 阶段与 run 阶段是两套上下文：镜像构建时若需要拉基础镜像或下载依赖，BuildKit 会读取 HTTP_PROXY等（可在 compose 的 build.args或守护进程环境中配置）。运行时容器若缺省这些变量，会出现「镜像能 build、进容器却 curl 不通」的割裂感，排查时要分别验证两段的变量是否一致、宿主机地址在 build 网络里是否可达。

CI 流水线里常见模式是 runner 与本机不同：有时是裸机 Docker，有时是 DinD。此时「宿主机」到底是谁要想清楚——代理进程实际跑在哪张网卡、哪条路由上，再把 HTTP_PROXY指向那个可达 IP。盲目照抄本地 172.17.0.1在远程 runner 上往往失效。与纯容器场景相邻的另一条线是 IDE 与包管理域名分流，可参阅 Cursor 与开发者域名分流，把宿主机桌面侧规则与 CI 侧变量策略分开维护，避免一条过宽规则误伤内网 Registry。

5. 方案二：Linux 网关思路与和「环境变量法」的差异

第二类路径从Linux 网关叙事理解：你希望某张自定义 bridge 上的容器默认下一跳指向宿主机，再由宿主机上的iptables / nftables + redsocks / tun 栈或Clash TUN接管。这类方案能覆盖「根本不读 HTTP_PROXY」的进程，但复杂度与权限要求明显高于环境变量法，且要与内核的 ip_forward、反向 SNAT、DNS 劫持等细节打交道，不适合作为第一篇入门读物的默认推荐。

实测对照里可以记住一句结论：环境变量法解决的是应用愿不愿意走代理；网关法解决的是包层面默认往哪送。若你只做 GitHub / npm / PyPI 这类 HTTPS 拉取，前者通常足够；若你要在容器里跑任意二进制且无法注入变量，才值得评估后者。无论哪条，宿主机 Clash的规则集仍然决定出口国家与策略组，容器并不会 magically 绕过你的 GEOIP或域名规则——前提是流量确实进了内核。

--network host让容器共享宿主机网络命名空间，有时能「省事」地直接用 127.0.0.1:端口访问本机代理，但会牺牲网络隔离，与 compose 多服务端口冲突风险并存，仅在明确可控的开发场景下短期使用更合适。生产与多租户环境应避免把 host 网络当默认答案。

6. Git、npm、pip 与 NO_PROXY 常见坑

Git：https://远程一般尊重 HTTP_PROXY；[email protected]:这种 SSH 协议不会自动走 HTTP 代理，除非你再配 ProxyCommand或改用 HTTPS 协议 URL。排错时先看远程 URL scheme，再看 GIT_CURL_VERBOSE=1一类调试输出。

npm / yarn / pnpm：多数会继承环境变量；企业内网私服域名务必写入 NO_PROXY，否则私有 Registry 也被送到公网节点，表现为诡异超时。Python pip同理，可配合 --proxy或环境变量；Poetry、uv 等工具请查阅其各自文档是否完整继承标准变量。

NO_PROXY建议同时列出 localhost、127.0.0.1、内网网段与集群 DNS 名后缀，并注意部分运行时只识别大写或小写变量名——若一端设了 no_proxy另一端只认 NO_PROXY，会出现间歇性行为。此类问题与容器出站是否经过 Clash无关，却是实测中最耗时的「假阳性」来源。

7. 两种路径对照小结

下表便于你在文档或团队规范里快速选型（「复杂度」为经验性相对值，随发行版与内核能力浮动）：

若你希望规则层面的细节（策略组顺序、url-test与 fallback）与本文容器接线一起考虑，可继续读 策略组 url-test 与 fallback，把「出口选谁」与「容器怎么接到出口」分成两层维护，长期更清晰。

8. 排查清单