Hostwinds部署Docker后UFW拦不住端口？公网入口应怎样验收

在Hostwinds上部署Docker站点，网页能访问、UFW也显示启用，数据库端口却仍可能暴露在公网。这个矛盾发生在流量经过的规则链上：容器发布端口改变了数据包的转发路径，主机入站策略未必拦得到它。采购时真正需要交付的，是一份外部可以验证的访问边界；增加内存或换一台VPS，并不会自动修正相同的端口映射。

先决定哪些连接应该失败

设一个小站由宿主机上的反向代理、应用容器和数据库容器组成。预期公网只访问网站入口，数据库只接收应用网络的连接，管理接口只允许管理员使用。验收应从这份需求出发：网站入口成功，公网直连数据库失败，非管理来源访问后台也失败。这里是部署情景，并非Hostwinds实际发生过的安全事故，也没有对商家网络进行扫描。

测试时要用自己有权管理的目标，在另一台真正位于外部网络的设备发起连接。只在VPS内执行请求，既不能验证公网过滤，也不能区分回环地址、私有网络与公网接口。保存目标地址、协议、端口、来源地址和测试时间；同时分别记录允许与拒绝的结果。超时也可能来自服务没有启动或路由故障，因此应结合应用监听与规则计数确认拒绝发生的位置。

UFW的状态，为什么不能解释容器入口

Docker官方文档明确指出，Linux上的桥接网络需要防火墙规则实现隔离、端口发布和过滤。它同时说明Docker与UFW使用规则的方式存在兼容问题：发布端口的数据包在经过UFW通常使用的INPUT和OUTPUT链之前，就会被NAT处理并转送。[1] 因而，UFW显示默认拒绝入站，不足以证明已发布的容器端口不可从外部访问。

例如把宿主机8080映射到容器80，不指定宿主机地址时，默认发布会使端口对外可用；具体还要看网络模式、路由与其他过滤层。[2] 运维者若只按普通宿主机进程的方式查看入站规则，就可能漏掉转发流量。这个问题与套餐有几核CPU没有直接关系，迁移时原样复制Compose配置，也会复制同一个暴露条件。

也不能为了让规则“归一”就直接关闭Docker的iptables或ip6tables处理。官方文档警告，这通常会破坏容器网络；如果没有完整的替代规则，还可能造成意料之外的可达性。[1] 修复应围绕需要保留的连接关系设计，而不是以某个状态栏变成绿色作为结束条件。

少发布一个端口，通常比多加一条补丁规则容易交接

如果只有宿主机反向代理需要访问应用，可以考虑明确绑定回环地址，例如官方示例中的127.0.0.1映射；数据库仅供同一容器网络使用时，可评估完全不发布到宿主机。[2] 这两种选择都需要与现有应用连接方式核对，不能只删映射而不检查依赖。若代理本身也是容器，容器里的回环地址不等于宿主机回环地址，应按容器网络中的服务地址组织连接。

版本条件必须保留。Docker文档特别提醒，28.0.0之前的版本，处于同一二层网段的主机可能访问绑定localhost的发布端口。[2] 因此，不能把旧版本上的回环绑定写成绝对隔离保证。采购交接至少应记录引擎版本、网络模式、绑定地址与地址族；IPv4验证通过，也不能直接替代IPv6验证。若使用host、macvlan或直接路由模式，本文默认桥接发布的路径分析也需要重新核对。

保留公开映射时，把规则放在实际经过的位置

在采用iptables后端的Docker配置中，DOCKER-USER链用于放置先于Docker后续转发链处理的用户策略。把规则追加到FORWARD末尾，可能已经晚于Docker的接受规则，无法产生原本期待的约束。[3] 但这不是让所有系统都照抄同一组命令：当前Docker也支持nftables后端，先确认实际后端，再使用对应文档与规则设计。[1]

另一个常见误判是匹配端口时忘记转换。数据包抵达DOCKER-USER时已经经过DNAT，普通匹配看到的是容器内部地址和端口。若公网8080转向容器80，却仍然按转换前的8080写条件，就可能漏掉目标连接。官方提供通过conntrack匹配原始目的地址和端口的方式，同时提示这种扩展可能带来性能下降。[3] 规则设计需要说明匹配的是转换前还是转换后的字段。

来源白名单也应限定作用范围。整条转发链上的粗放丢弃，可能影响其他容器、出站响应或主机承担的路由任务。变更前保留规则快照和可用的管理入口，先验证既有连接与新连接，再验证拒绝范围。重启Docker、重启主机以及重新创建容器后，应重复同一份验收，确认规则能够按预期恢复，而不是仅在本次终端会话里有效。

Hostwinds的外部防火墙，需要单独交付证据

本次读取Hostwinds非托管Linux VPS官网，页面将Firewall描述为运行在服务器操作系统环境之外、用于管理进出流量的防火墙，并列出完整root访问权限。FAQ同时说明非托管方案由用户承担系统维护，商家确保实例及基础连接可用，不提供其他技术、管理或行政支持。[4] 产品介绍能够确认服务方向，不能证明某个新实例已绑定了正确的防火墙规则。

外部防火墙可以成为主机配置之外的一层限制，但采购时仍须逐项确认：规则组绑定到哪个实例、默认方向是什么、IPv6是否有对应策略、变更后多久生效。本文没有进入客户账户验证这些项目，也没有证据承诺其默认配置能挡住所有Docker映射。只有在目标实例上实际关联规则，并由外部测试复核，产品功能才成为这次部署的有效边界。

想比较可用方案，可通过Hostwinds服务器套餐推广入口核对当前订单。此链接含推广关系。选择非托管服务前，宜把Docker网络、主机过滤和外部规则的维护人写入交付清单；是否购买额外管理服务，要向商家确认容器规则是否在支持范围内，不能从“有防火墙”推导出“有人替你维护所有规则”。

费用也应围绕这个交付条件计算。若两种候选方案的月费差额为每月10美元，团队内部维护成本假设为每小时30美元，那么差额对应每月20分钟维护时间。这是预算算例，不是商家的实际报价或承诺。规则审查、版本升级后回归、告警接手与误封回滚都消耗人力；若较贵方案没有覆盖这些工作，不能把全部差额当成已经买到的运维时间。反过来，现有自动化已能稳定执行验收时，也没有必要仅因本问题购买更多CPU。

正式付款或迁移之前，留下实际生效配置、允许与拒绝的外部结果、重启后的复测记录以及故障接手人。判断是否达标应以预期访问关系为准：需要开放的入口可靠可用，需要封闭的入口在相关地址族和网络路径上确实不可达。后续更改端口映射、代理位置或防火墙后端时，重新执行这份记录中的检查；一份旧的UFW状态截图无法代表变更后的容器网络。

资料来源与边界

技术依据为本次读取的Docker在线文档，适用行为需对照部署版本和后端；商家依据为本次可读取的Hostwinds官方产品文字与渠道推广记录。没有购买、扫描或性能实测；未核实订单库存、续费、退款以及具体账户防火墙配置。正文两张图片为示意，不充当功能验证证据。

Sources:
[1] https://docs.docker.com/engine/network/packet-filtering-firewalls ， timer
[2] https://docs.docker.com/engine/network/port-publishing ， flock
[3] https://docs.docker.com/engine/network/firewall-iptables ， pgdump
[4] https://www.hostwinds.com/vps/unmanaged-linux ， Hostwinds非托管Linux VPS