主 题：Docker 开了 UFW，容器端口为什么还能从公网访问？附自查方法
发 布 者：Cliang
标签分类： 技术
时 间：2026-10-09 09:12:17
内容预览：给自建服务做防火墙时，容易出现一个误判：UFW 只放行了 SSH、80、443，于是认为容器的管理端口也被挡住了。但在 Linux Docker 常见的 bridge 端口发布场景里，容器流量经过的路径和宿主机普通进程不同。Docker 官方文档明确说明，发布端口的流量可能在进入 UFW 使用的 INPUT / OUTPUT 链之前就被转走。因此，ufw status 里的规则不能单独证明容器端口已经封住。官方说明先看这一行端口映射ports: - "8080:80"没写宿主机地址时，默认会发布到所有宿主机地址。对于只需要宿主机上的 Nginx / Caddy 访问的后端，可以明确绑定回环地址：ports: - "127.0.0.1:8080:80"然后宿主机上的反向代理访问 http://127.0.0.1:8080。这个做法适用于普通 bridge 的 NAT 模式；host 网络、Swarm、容器地址直路由等场景需要分别检查。Docker 28.0.0 之前还存在同一二层网络可访问 localhost 发布端口的历史问题，旧版本不能只靠这一行判断隔离。端口发布文档反向代理也在容器里，情况又不同反代容器里的 127.0.0.1 指向反代容器自身。如果反代和应用都跑在容器里，可以把它们接入同一个自定义 bridge 网络，让反代通过应用的服务名和容器端口连接，例如 http://app:80；应用不必再发布宿主机端口。数据库也一样，只供应用访问时，先考虑删除不必要的 ports。同一网络里的容器能相互访问，所以也别把无关服务全部塞进一个公共网络。bridge 网络说明自查可以按这个顺序来先检查容器发布了什么：docker ps --format 'table {{.Names}} {{.Ports}}'再对具体容器看完整映射，把 你的容器名 换成实际名称：docker
直达链接： https://www.nodeseek.com/post-971810-1
发 布 者：Cliang
标签分类： 技术
时 间：2026-10-09 09:12:17
内容预览：给自建服务做防火墙时，容易出现一个误判：UFW 只放行了 SSH、80、443，于是认为容器的管理端口也被挡住了。但在 Linux Docker 常见的 bridge 端口发布场景里，容器流量经过的路径和宿主机普通进程不同。Docker 官方文档明确说明，发布端口的流量可能在进入 UFW 使用的 INPUT / OUTPUT 链之前就被转走。因此，ufw status 里的规则不能单独证明容器端口已经封住。官方说明先看这一行端口映射ports: - "8080:80"没写宿主机地址时，默认会发布到所有宿主机地址。对于只需要宿主机上的 Nginx / Caddy 访问的后端，可以明确绑定回环地址：ports: - "127.0.0.1:8080:80"然后宿主机上的反向代理访问 http://127.0.0.1:8080。这个做法适用于普通 bridge 的 NAT 模式；host 网络、Swarm、容器地址直路由等场景需要分别检查。Docker 28.0.0 之前还存在同一二层网络可访问 localhost 发布端口的历史问题，旧版本不能只靠这一行判断隔离。端口发布文档反向代理也在容器里，情况又不同反代容器里的 127.0.0.1 指向反代容器自身。如果反代和应用都跑在容器里，可以把它们接入同一个自定义 bridge 网络，让反代通过应用的服务名和容器端口连接，例如 http://app:80；应用不必再发布宿主机端口。数据库也一样，只供应用访问时，先考虑删除不必要的 ports。同一网络里的容器能相互访问，所以也别把无关服务全部塞进一个公共网络。bridge 网络说明自查可以按这个顺序来先检查容器发布了什么：docker ps --format 'table {{.Names}} {{.Ports}}'再对具体容器看完整映射，把 你的容器名 换成实际名称：docker
直达链接： https://www.nodeseek.com/post-971810-1
