UFW里明明已经拒绝8080端口，外部网络却仍能打开Docker里的服务，这不是UFW状态显示错了。Docker发布端口时会创建自己的NAT与转发规则，数据包可能在到达UFW常用的INPUT规则前就被转向容器。
先确认容器到底绑定了哪个宿主机地址，再决定收紧端口映射还是增加Docker转发链规则。 直接停止Docker修改iptables，往往会把容器联网和端口映射一起破坏。
确认端口是否真的对所有地址发布
先查看运行容器的端口映射和宿主机监听：
docker ps --format 'table {{.Names}}\t{{.Ports}}'
docker inspect -f '{{json .NetworkSettings.Ports}}' app
sudo ss -lntp
sudo ufw status numbered输出里出现 0.0.0.0:8080->80/tcp，代表所有IPv4地址都可接收8080连接；出现 [::]:8080 还代表IPv6方向。只看到容器内部的 80/tcp 而没有宿主机端口，则不属于publish暴露。
不要只根据docker-compose.yml里的expose判断公网范围。 ports、命令行 -p 以及实际容器检查结果才决定宿主机如何发布。
Docker为什么会绕过UFW输入规则
Docker官方说明，bridge网络需要防火墙规则完成隔离、端口发布和NAT。发布端口的数据包会先在nat表中进行目标地址转换，再作为转发流量送往容器，因此不会按普通宿主机服务的路径进入UFW的INPUT链。
这也是 ufw deny 8080/tcp 对宿主机进程有效，却可能挡不住 docker run -p 8080:80 的原因。Docker还会创建DOCKER、DOCKER-FORWARD和DOCKER-USER等链处理容器流量。
UFW启用不等于Docker发布端口自动受同一套入站规则保护。 端口是否对外开放必须从外部网络实际验证。
最简单的收口方法是限制绑定地址
服务只供本机反向代理访问时，把端口绑定到loopback：
docker run -d --name app -p 127.0.0.1:8080:80 example/app:latestCompose可写成：
services:
app:
image: example/app:latest
ports:
- "127.0.0.1:8080:80"修改映射需要重建容器，单纯 docker restart 不会改变已有端口发布。对只应从私网访问的服务，也可以绑定宿主机指定私有地址。
数据库、管理面板和内部API不应默认发布到0.0.0.0。 绑定范围越小，后续防火墙误配置造成的风险越低。
需要外部访问时使用DOCKER-USER链
Docker使用iptables后端时，DOCKER-USER链会在Docker自己的转发接受规则之前处理管理员规则。先保留已建立连接，再仅允许可信来源进入外部接口：
sudo iptables -I DOCKER-USER 1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
sudo iptables -I DOCKER-USER 2 -i eth0 -s 203.0.113.10/32 -j ACCEPT
sudo iptables -I DOCKER-USER 3 -i eth0 -j DROP示例地址和接口必须替换为实际值，并通过控制台保留救援入口。数据包进入DOCKER-USER时通常已经DNAT，想按原始宿主机目标地址或端口精确匹配，需要使用conntrack的 --ctorigdst 与 --ctorigdstport；官方提醒这可能降低性能。
不要远程直接粘贴全局DROP规则。 先列出现有规则、确认SSH管理路径和容器出站需求，再以最小范围测试；规则持久化方式也要与发行版一致。
不要通过关闭Docker防火墙功能解决
把Docker daemon中的 iptables 或 ip6tables 设为false，会阻止Docker创建大部分规则，但官方明确指出这不适合多数用户，可能破坏bridge网络的NAT和互联网访问，某些端口反而仍可被本地网络访问。
需要安全复现时，可在 萤光云 创建与生产相同版本的临时VPS；跨网络验证公网暴露范围时，可用 LightNode 的按小时实例作为外部测试端。不要在测试机复制生产私钥或真实数据库。
Docker也支持iptables与nftables后端，不同版本和后端的链结构存在差异。应用规则前先查看 docker info、daemon配置以及当前规则集，不能把iptables命令机械套到实验性nftables后端。
从外部网络完成最终验收
在VPS本机测试只能证明服务运行，不能证明公网访问控制正确。使用不在白名单中的外部主机测试端口，再从允许地址验证业务：
nc -vz SERVER_IP 8080
curl -I --connect-timeout 5 http://SERVER_IP:8080/同时检查规则计数与容器日志，确认流量确实命中预期链。重启Docker和服务器后再测一次，防止规则没有持久化或启动顺序改变。
验收标准应是非授权来源连接失败、授权来源可用、SSH管理不受影响，并且重启后策略仍然有效。 只看UFW显示active不能证明Docker端口已收口。
FAQ
只删除UFW的allow规则够吗？
不一定。Docker发布端口可能绕过UFW常规INPUT路径，应同时检查端口绑定和Docker转发链。
把容器端口改成其他数字安全吗？
改端口只能减少随机扫描，不能形成访问控制。仍应限制绑定地址、来源范围并启用应用认证。
为什么修改Compose后端口仍然开放？
端口映射属于容器创建配置，需要重新创建容器。还应检查旧容器是否仍在运行，以及IPv6映射是否保留。
温馨提示
防火墙变更最容易把远程管理员锁在门外。操作前保存当前规则、保留云控制台或救援连接，并优先通过缩小Docker绑定地址减少暴露面。
