Docker容器怎么走VPN？为什么宿主机能访问，容器却不行？

Docker容器怎么走VPN？先确认你要代理的是容器里的应用。宿主机浏览器能打开网页、Docker能拉取镜像，都不能证明这个应用已经使用VPN出口。请求可能从不同的网络环境发出，代理设置也可能只作用于其中一个阶段。

本文面向自行管理Docker的用户，给出运行中容器的检查方法，以及共享VPN容器网络的配置片段。资料依据Docker与Gluetun官方文档整理，未在你的NAS或电脑上实测；示例不包含可直接使用的VPN账号配置。

先找出真正发请求的进程

想象你在NAS上运行一个下载应用。浏览器负责打开它的管理页面，真正下载文件的是NAS里的容器进程。电脑上的VPN只能影响它实际接管的流量，不会因为浏览器连上NAS，就顺带代理NAS的下载任务。

先填清楚下面这张表，比反复切换节点更有用。

如果问题发生在镜像下载阶段，直接看Docker拉取镜像的代理排查。下面只处理容器已经创建后的网络。

按应用能力选择接入方式

应用支持HTTP或SOCKS代理时，优先查看应用自己的代理设置。这样能明确知道哪些请求受设置控制，也容易撤回。需要确认它是否分别处理下载、订阅更新和其他网络任务，不能只测试登录页面。

应用只支持代理环境变量时，可以在创建容器时传入相应变量。但环境变量不会强制接管所有程序，Docker官方说明也提醒，各应用对变量的处理没有统一标准。变量已经出现，只说明配置传进去了。

如果需要让不支持代理的应用使用一个隧道出口，可以考虑让应用共享专门VPN容器的网络空间。此时要同时处理路由、DNS、防火墙和管理端口，维护成本更高。

购买一条VPN线路，不等于已经获得兼容Docker的部署方案。先确认服务商提供的协议、认证资料与所选VPN容器兼容，再决定使用哪一种方式。

容器里的本地地址指向谁

默认隔离的容器有自己的网络环境。应用填写127.0.0.1:7890时，通常寻找的是容器自身的7890端口，无法直接指向电脑或NAS上同名的本地代理。

Docker的容器网络说明专门指出，容器内的回环地址属于容器自身。Docker Desktop、Linux Engine以及NAS厂商的网络实现有差异，不能把一个平台的主机访问地址照搬到另一个平台。

先核对代理监听地址，再确认容器能到达它。如果代理仅监听宿主机回环地址，随意改成监听所有网卡可能扩大访问范围。应限制允许访问的来源，并设置必要的认证，不要为了让容器连上而把无认证代理暴露到公网。

如果仍分不清系统代理和隧道接管，可以先看TUN模式与系统代理的区别。宿主机打开TUN后，转发的容器流量是否被接管，仍要实际验证。

共享VPN容器网络要改哪些地方

Docker Compose支持用network_mode: "service:vpn"让应用共享另一个服务的网络空间。这种写法不负责创建VPN，也不会自动产生断网保护。Compose网络文档说明了这一模式的含义。

假设同一个Compose项目中，已经有一个配置完成、能正常联网的vpn服务，可以在原有配置中调整应用部分：

services:
  app:
    network_mode: "service:vpn"
    depends_on:
      - vpn

这只是需要合并的结构片段，app仍须保留原有镜像、数据卷和应用参数；项目里也必须实际定义vpn。不要把它当成完整配置直接启动。

以Gluetun为例，其端口映射说明要求把应用需要发布的端口放到Gluetun服务上。应用共享网络后，不应继续照搬原来的独立网络与端口声明。

例如应用在容器内监听8080，管理页面只供宿主机访问时，可以在vpn服务发布127.0.0.1:8080:8080。若需要局域网访问，则另外确定监听地址、允许来源和登录保护。端口发布的位置改变后，原来保存的管理页面地址也要重新测试。

用同一个应用做连接和断线验证

先保存原Compose文件与应用代理设置，在测试副本中调整。记录宿主机出口、容器内出口和实际任务结果，避免只拿浏览器的IP作为结论。

如果应用镜像自带curl，可以把app替换成真实服务名后执行：

docker compose exec app curl --connect-timeout 5 --max-time 10 https://ip.me

它只验证这个curl请求。镜像没有curl时，不必直接给生产容器安装工具，可以改用应用日志或在测试环境安排诊断容器。还要测试应用实际使用的协议，单次HTTPS成功不能代表UDP与IPv6都符合预期。

随后在测试环境断开VPN隧道，观察任务是否停止、是否出现直连出口，再恢复隧道，检查应用能否重连。测试对象应包括隧道失联和VPN容器重建，二者不一定有相同结果。

depends_on默认的启动顺序不能替代VPN就绪检查。Gluetun的健康检查说明也应结合实际配置阅读。即使设置了就绪条件，也要验证运行中掉线后的防火墙行为。

验收时分别记录“能联网”“出口正确”“失联后符合预期”“恢复后应用可用”。任何一项失败，都先恢复原配置，再根据失败阶段排查；不要同时更换镜像、DNS和VPN协议，否则很难确认是哪项设置起了作用。

常见问题

宿主机开VPN后，容器会自动走VPN吗？

不能一概而论。容器使用的网络模式、宿主机路由以及VPN对转发流量的处理都会影响结果。应从容器内和实际应用分别验证。

设置HTTP_PROXY后所有容器流量都会被接管吗？

不会。只有采用该变量的程序及请求会受影响，应用可能忽略变量，也可能为不同任务使用独立网络设置。

network_mode改成host就能解决吗？

host模式共享主机网络，改变了隔离与端口行为，但不会自动建立VPN或断线保护。不同平台还存在支持条件，不能当成通用修复开关。参见Docker host模式文档。

VPN容器重建后，应用需要重建吗？

可能需要重新创建关联的应用容器，使其进入新的网络空间。应按所用VPN容器项目的部署说明操作，并重新验证管理端口、出口与断线行为，不能只看两个容器都显示运行中。