美国高防云服务器上跑Docker，安全边界和普通云服务器有一个根本性的不同：高防清洗的是从外部进来的流量，而Docker容器网络一旦配置不当，攻击者可能完全绕过清洗层，从宿主机内部或者容器之间的横向移动直接触及源站。换句话说，高防解决的是“外面打进来”的问题，但Docker的网络隔离和端口暴露如果没做对，攻击面会从外部转移到内部，清洗设备对此无能为力。

　　容器网络隔离和端口管控，本质上是在回答一个问题：谁有权访问容器，以及容器之间能不能互相访问。默认配置下，Docker给出的答案对安全并不友好。

　　默认桥接网络的隐患：容器之间没有墙

　　Docker启动时会自动创建一个名为bridge的默认网络。所有没有指定网络的容器都会接入这个桥接网络，它们之间默认是互通的。这意味着，如果一个容器被攻破，攻击者可以直接访问同一宿主机上其他容器的所有端口，不需要经过任何防火墙规则。在高防服务器上，这个风险被放大——攻击者一旦通过某个暴露的服务进入容器，横向移动的成本几乎为零。

　　更隐蔽的问题在于默认桥接网络不做容器名到IP的自动DNS解析。多容器应用在默认桥上只能靠IP互访，运维人员为了省事，往往把容器端口直接映射到宿主机0.0.0.0，用宿主机IP加端口来通信。这种做法把容器服务完全暴露在公网接口上，Docker的端口映射规则写进nat表的DOCKER链，直接绕过了宿主机上INPUT链的防火墙规则。也就是说，你在ufw或firewalld里禁止了某个端口，Docker照样把流量转发到容器里，防火墙形同虚设。

　　自定义桥接网络：隔离的起点

　　解决容器间互通问题的第一步，是放弃默认bridge，为每一组需要互相通信的容器创建独立的用户自定义桥接网络。

docker network create \
  --driver bridge \
  --subnet 172.20.0.0/16 \
  --gateway 172.20.0.1 \
  app-backend

　　自定义桥接网络有两个关键差异。第一，它内置了DNS解析，容器可以通过名称互相访问，不需要依赖脆弱的IP硬编码。第二，不同自定义网络之间的容器默认不通。前端容器放在frontend网络，数据库放在backend网络，只有明确接入两个网络的容器(比如应用服务器)才能跨越边界。数据库容器的端口不需要映射到宿主机，它只在backend网络内可达，外部扫描器扫不到它。

　　对于完全不需要外网访问的服务——比如内部缓存、消息队列、或者只被其他容器调用的API——可以创建internal: true的网络。这个网络没有到宿主机外部接口的路由，容器只能在这个网络内部通信。对于高防场景下那些“只应该被清洗后的流量触及”的后端组件，这是最干净的隔离方式。

　　端口管控的核心：不要用0.0.0.0

　　docker run -p 8080:80这种写法，等价于-p 0.0.0.0:8080:80，把容器的80端口映射到宿主机所有网络接口上。如果这台服务器有公网IP，这个端口就对全世界开放，高防清洗的流量过滤完全不适用于这个入口——攻击者直连宿主机的8080端口，流量根本不经过高防IP。

　　正确的做法是只绑定到回环地址，把公网入口给反向代理统一管理：

docker run -d -p 127.0.0.1:8080:80 nginx

　　这样容器服务只在127.0.0.1:8080上监听，公网无法直接访问。然后在宿主机上部署Nginx或Traefik，监听443和80，反向代理到127.0.0.1:8080。所有外部流量先经过反向代理，再由代理转发到容器。反向代理层可以做TLS终止、请求过滤、速率限制，而且高防清洗后的流量也是从公网IP进入宿主机，再经过反向代理到达容器——路径是完整的，没有被绕过的缺口。

　　如果某些服务确实需要直接暴露公网端口(比如游戏服务器的UDP端口、或者非HTTP协议的服务)，至少应该在Docker的DOCKER-USER链里做源IP限制。DOCKER-USER是Docker专门留给用户自定义规则的链，它在Docker自己的转发规则之前生效，不会被Docker重启清空。例如只允许特定IP访问某个端口：

iptables -I DOCKER-USER -p tcp --dport 8080 ! -s 203.0.113.0/24 -j DROP

　　但这只是治标，对于HTTP类服务，绑定回环加反向代理仍然是更可控的方案。

　　高防场景下的特殊考量：源站IP不能在容器层暴露

　　美国高防云服务器的防御逻辑依赖一个前提：攻击流量打到高防IP，清洗后回源到源站。如果Docker容器直接把端口映射到公网，攻击者可以绕过高防IP，直接向源站IP的容器端口发起攻击。源站没有清洗能力，容器所在宿主机的带宽和连接数很快会被打满。

　　因此，Docker环境的端口暴露策略必须与高防架构对齐。所有对外提供服务的容器，都不应该直接在宿主机公网接口上监听。正确的链路是：高防IP → 清洗中心 → 源站宿主机公网IP → 宿主机反向代理(监听443/80)→ 回环地址上的容器。容器层面的端口映射只绑定127.0.0.1，宿主机防火墙只放行反向代理需要的端口，其他一律拒绝。这样即使某个容器存在未修补的漏洞，攻击者也无法通过扫描源站IP的端口来发现它。

　　另一个容易被忽略的点是Docker守护进程本身的暴露。/var/run/docker.sock如果被挂载进容器，容器内的进程就拥有了控制宿主机Docker的权限，可以启动特权容器、挂载宿主机文件系统。这是容器逃逸的经典路径，在高防服务器上意味着攻击者可以从一个被攻破的Web容器直接接管整台宿主机，高防清洗完全失去意义。除非绝对必要，不要挂载docker.sock；如果必须挂载，使用只读模式，并限制容器以非root用户运行。

　　一个完整的配置检查清单

　　在部署任何容器之前，确认以下几条已经就位。

　　1. 默认桥接网络是否还在被使用。 运行docker network ls，如果业务容器仍然挂在bridge上，迁移到自定义网络。默认桥接的容器互通和缺乏DNS解析，是运维便利性和安全性双重意义上的负担。

　　2. 端口映射是否绑定了127.0.0.1。 检查所有docker run或docker-compose.yml中的ports配置，任何以0.0.0.0或未指定IP的映射都需要修改。对于只在容器间通信的服务，直接删除ports配置，改用expose声明端口(expose只在容器网络内生效，不映射到宿主机)。

　　3. 防火墙规则是否写在了正确的位置。 宿主机上如果启用了ufw，不要指望它能拦住Docker暴露的端口。需要限制的入站连接，规则写在DOCKER-USER链里，或者通过反向代理的访问控制来实现。

　　4. 敏感服务是否在独立网络中。 数据库、缓存、消息队列不应该和面向公网的Web容器在同一个自定义网络中。为后端服务单独创建网络，只让应用服务器接入两个网络作为桥梁。

　　常见问答

　　Q：Docker的-p 127.0.0.1:8080:80和-p 8080:80有什么区别?

　　A：前者只把容器的80端口映射到宿主机的回环地址，公网无法直接访问；后者映射到宿主机所有接口，包括公网IP，任何能访问宿主机的人都能连上这个端口。在高防场景下，后者的流量不经过高防清洗，直接暴露源站。

　　Q：已经在用ufw了，为什么Docker端口还是对公网开放?

　　A：Docker的端口映射规则写在nat表的DOCKER链里，数据包在到达ufw管理的INPUT链之前就被DNAT转发到容器了。ufw管不到Docker的转发路径。限制Docker暴露端口要么用DOCKER-USER链，要么从源头就不做公网映射。

　　Q：容器之间需要通信，但又不想让它们互相访问所有端口，怎么做?

　　A：使用多个自定义桥接网络做分段。比如前端容器接入frontend网络，后端API容器同时接入frontend和backend网络，数据库只接入backend网络。前端只能访问API容器在frontend网络中监听的端口，接触不到数据库。这是网络分段的基本做法，不需要在容器内部写复杂的防火墙规则。

　　Q：高防清洗过的流量，到容器这一层还需要做什么?

　　A：清洗解决的是流量层面的攻击过滤，但容器层面的访问控制是独立的。即使流量经过了清洗，也不应该让容器直接监听公网端口。反向代理加回环绑定的架构，确保清洗后的流量仍然经过宿主机层面的访问控制，而不是直接灌入容器。两层各司其职，缺一不可。