容器发布端口为什么需要单独防护
一个反直觉的事实
很多人栽在这个坑里：系统防火墙明明没放行 3306，公网却连得上容器里的 MySQL。原因是 Docker 的端口发布走自己的转发链路，请求在到达系统防火墙的常规规则之前就被转发进容器了——这是 Docker 在所有平台上的标准行为，不是 1Panel 的问题。
官方文档为此在防火墙下专门做了「Docker 端口防护」页面，作用是限制外部访问 Docker 已发布端口的来源。
首次启用
防火墙设置页选好支持 Docker 防护的后端（iptables 或 nftables，firewalld/UFW 不支持这一层），然后到「Docker 端口防护」页初始化。防护生效后面板会基于容器的端口发布情况自动维护对应策略。
防护模式与生效状态
防护页可以对不同容器端口设置来源限制，逻辑与系统防火墙的规则类似：允许所有、允许指定 IP 或网段。生效状态列会标注策略是否已在内核层落地；「孤立策略」指容器已删但策略残留的情况，可以在页面里清理。
官方文档为这层功能准备了导入、导出与同步机制：多台机器之间可以导规则文件复用；重启 Docker 或重启服务器后策略丢失时用同步恢复。
什么时候需要它
用三个场景判断：
- 全内网服务（数据库、缓存）：根本不发布对外端口，容器网络内互访，这层防护是兜底；
- 只对固定 IP 开放的管理端口（phpMyAdmin、Portainer）：防护层配指定 IP，比裸奔安全得多；
- 正经对外的网站端口（80/443）：正常放行，配合网站层的 HTTPS 与 WAF（专业版）做纵深。
对应到操作习惯：装应用时「暴露外部端口」的选择要慎重，见安装应用；能收进反向代理的服务尽量不直接暴露端口。