记录一下最近解决的局域网与容器代理连通性问题。
最近遇到的神秘的情况终于解决了：像rss可以拉取来自一些外网网站的订阅并发送到群里，但是无法正常读取国内的镜像站，然后甚至Docker也出现无法拉取到镜像
还有就是Napcat、Koishi都无法拉取到插件商店的问题。
这些一开始都是正常的，直到我使用十几个小时后，突然开始连不上。
网上的说法不一，比如有说在 WSL架构下，Docker Desktop 和宿主机代理软件经常会产生网络隔离、DNS 冲突和解析死循环等等…但是我目前只是一个容器小子，qwq叽里咕噜说什么呢））
然后摸索出了一套设置来解决这种问题
环境
- 操作系统：Windows 11
- 代理工具：Clash Verge
- 底层环境：WSL
- 容器平台：Docker Desktop
1. 适用场景
- 宿主机使用代理，需要让 Docker 引擎正常拉取镜像。
- 容器内部应用（特别是使用 Node.js 原生
fetch忽略环境变量的应用）需要通过宿主机代理访问外部 API。 - 存在“国内外分流”需求，即国内服务（如 npmmirror、阿里云）需绕过代理直连，国外请求走代理。
- 遇到 Docker Desktop 客户端一直转圈无法登录，或容器内报错
lookup host.docker.internal: no such host的情况。
2. 本文未考虑的场景
- 纯 Linux 系统下的原生 Docker 部署（无 WSL 层参与）。
- 软路由或网关级别的透明代理环境。
- WSL 网络模式设置为
Mirrored（镜像模式）的情况（本说明基于更常见的NAT模式）。 - k8s 等复杂容器编排工具的网络插件配置。
3. WSL 底层网络设置
进入 Windows 设置 → 适用于 Linux 的 Windows 子系统。核心是打通本地回环并关掉系统自带的干扰项。
- 网络模式：Nat
- 启用 localhost 转发：开（核心设置，允许虚拟机内的 127.0.0.1 映射到宿主机）
- 启用 DNS 隧道：关（必须关，否则会劫持容器内部解析导致本地内部域名失效）
- 启用自动代理：关（避免系统变量污染容器环境变量）
- 启用 Hyper-V 防火墙：关
注意： 修改完成后，打开 PowerShell 执行wsl --shutdown彻底重启子系统以应用配置。
4. Clash Verge 设置
确保代理允许局域网流量，并且不接管底层网卡。
- 系统代理：开
- 虚拟网卡模式 / TUN 模式：关（防止接管路由导致 Docker 桥接网卡瘫痪）
- 局域网连接 (Allow LAN)：开
- DNS 覆写：关
- 端口设置：7897（按需修改，本文以此为例）
5. Docker Desktop 客户端设置
为了让 GUI 客户端自身有网且不陷入 DNS 解析死循环。
进入 Settings → Resources → Proxies：
- 打开 Manual proxy configuration。
- Web Server / Secure Web Server：填写
http://127.0.0.1:7897 - Bypass proxy settings：填写
localhost,127.0.0.1,host.docker.internal - 点击 Apply & restart。
6. docker-compose 业务配置模板
在具体业务的 docker-compose.yml 中，强制映射网关地址，并通过环境变量和 DNS 配置实现分流。
将以下内容加入到各个需要联网的 service 节点下：
# 强制本地解析，绕开外部 DNS，解决 no such host
extra_hosts:
- "host.docker.internal:host-gateway"
# 注入代理变量并设置直连白名单
environment:
- TZ=Asia/Shanghai
- HTTP_PROXY=http://host.docker.internal:7897
- HTTPS_PROXY=http://host.docker.internal:7897
# 排除本机环回、容器互访、国内直连域名以及 Docker 自带的网段
- NO_PROXY=localhost,127.0.0.1,host.docker.internal,koishi,napcat,.cn,.npmmirror.com,.aliyuncs.com,192.168.65.0/24,172.16.0.0/12
# 强制使用国内公共 DNS，防止被代理软件劫持
dns:
- 223.5.5.5
- 119.29.29.29
这里是以我自己有的容器两个联网性比较强的koishi,napcat为例，所以NO_PROXY尝试加了，可以删去。暂时没有测试删去后是否有影响。因为我的koishi和napcat实际上是建立一个虚拟网络bot-net来互相联通的
保存配置后，在终端执行 docker compose down 销毁旧容器，再使用 docker compose up -d 重建，确保新的网络环境和变量完全注入。
部分硬编码不读取环境变量的应用，可能需要在本地挂载的 JSON 配置文件中手动写死代理地址。我暂时没有测试这方面。
经过以上配置，docker desktop自身的登录问题解决了，容器里一部分网络服务可用另一部分不可用的问题也解决了qwq，恢复成应有的样子。。但是本文可能有不严谨的方案，因为我用这些工具还没多久，可能有一些冗余设置或者错误的理解，还请大佬指出！或者有前辈写过更合理的配置的话，希望也有大佬可以指路！