解决Docker与UFW的经典冲突：为什么端口没开却能访问？

在Linux服务器管理过程中，很多管理员都遇到过这样一个令人困惑的现象：明明用UFW（Uncomplicated Firewall）没有开放某个端口，但运行在Docker容器中的服务却依然能够从外部访问。这个看似矛盾的问题，其实背后有着清晰的技术原因。
问题现象
当你检查UFW状态时，可能会看到这样的结果：

显然，除了SSH的22端口外，没有开放其他端口。但奇怪的是，运行在8080端口的Docker服务却能被外部正常访问。

一、根本原因：iptables规则优先级

问题的核心在于Docker和UFW在Linux防火墙体系中的交互方式。
数据包处理流程：
原始数据包 → iptables PREROUTING链 → Docker的DOCKER链 → UFW的规则（被绕过！）
Docker为了容器网络功能正常工作，会在iptables中创建自己的规则链，这些规则的优先级高于UFW的规则链。这意味着数据包会先被Docker的规则处理，等轮到UFW时，可能已经被Docker"放行"了。

二、深入技术细节

查看iptables规则可以清楚地看到问题所在：

# 查看Docker创建的规则链
sudo iptables -L DOCKER -n -v
sudo iptables -L DOCKER-USER -n -v

你会看到Docker自动添加的规则，比如：

这些规则在UFW规则之前被执行，导致了看似"绕过"防火墙的现象。
解决方案
方案一：修改Docker配置（推荐用于开发环境）
编辑Docker配置文件 /etc/docker/daemon.json：

{
"iptables": false
}

重启Docker服务：

sudo systemctl restart docker

注意：设置后Docker不再自动管理iptables，需要手动设置端口转发。

方案二：使用UFW的Docker集成
安装UFW Docker集成包并添加规则：

sudo apt update 
sudo apt install ufw-docker 

# 允许特定端口

sudo ufw allow proto tcp from any to any port 8080

方案三：手动调整iptables规则顺序
创建修复脚本，确保UFW规则在Docker规则之前执行：
#!/bin/bash

sudo iptables -I INPUT -j UFW-USER-INPUT 
sudo ufw disable && sudo ufw enable

方案四：使用反向代理（生产环境强烈推荐）
这是最安全可靠的方案。让Docker容器只监听本地回环地址：
# docker-compose.yml

version: '3'
services:
myapp:
image: myapp:latest
ports:
- "127.0.0.1:8080:8080" # 只绑定到本地

然后用Nginx作为反向代理：

server {
listen 80;
server_name your-domain.com;

location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
}
}

UFW只需开放80/443端口：

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

验证修复效果
修复后，你应该验证：
1.UFW状态
2.从外部测试端口访问应该被拒绝
3.只有在明确允许后才能访问
# 修复前：即使UFW没开端口也能访问
telnet 你的服务器IP 8080
# 修复后：访问被正确拒绝

总结

Docker与UFW的集成问题源于iptables规则优先级的设计选择。理解这一机制后，我们就可以根据实际需求选择合适的解决方案：开发环境可以选择方案一或二，生产环境强烈建议使用方案四的反向代理方案，既能保证安全性，又便于维护管理。
通过正确配置，我们既可以享受Docker带来的便利，又能确保服务器的网络安全不受影响。