#防火墙

通过 主机 → 防火墙，可以管理主机入站访问、Docker 容器发布端口和端口转发规则。

本文适用于包含 主机防火墙、容器端口防护、端口转发、设置 四个入口的新版页面。若当前仍显示“端口规则、IP 规则、iptables 高级控制”，请先核对所用版本及升级说明。

#1 选择需要的功能

#2 首次使用

1. 进入 设置，确认各功能使用的防火墙管理方式。
2. 启用主机防火墙前，在 端口白名单 中配置需要持续访问的面板、SSH 和业务端口，核对协议、允许来源及 IPv4 / IPv6 范围，保留一个可用的 SSH 会话。
3. 返回需要使用的功能页，按顶部提示启动服务或初始化规则。主机防火墙初始化会同时绑定规则，默认拒绝策略随即生效；尚未放行的业务端口将无法建立外部新连接。
4. 等待任务完成，确认对应 IP 版本的状态正常，从其他设备重新连接面板、SSH 和业务服务验证，再按需要添加或收紧访问规则。

首次启用前先确认业务端口。 当前 iptables、nftables 主机防火墙先处理内置保护和端口白名单，再匹配自定义规则，最后丢弃其余 TCP/UDP 入站流量。因此，未添加允许规则的业务端口默认无法建立外部新连接，无需逐个端口添加拒绝规则；已有 SSH 会话正常并不能证明新连接也正常。firewalld、UFW 的默认访问策略需结合其现有配置判断。

主机防火墙支持 iptables、nftables、firewalld、UFW；端口转发和容器端口防护支持 iptables、nftables。可选项取决于服务器已安装的组件和支持情况。当前版本的容器 nftables 后端要求 Docker ≥ 29.0.0，属于实验性支持，Docker 处于 Swarm 模式时不能启用，详见 Docker 官方说明。

使用 iptables、nftables 时，初始化会创建所需规则并接入实际流量；绑定用于让已初始化但解绑的规则重新生效。主机防火墙和容器端口防护解绑后，配置可以保留，但相关限制不再生效。使用 firewalld、UFW 时，应确认服务处于启动状态。

使用 firewalld 时，面板管理的是 public zone 中的主机入站规则。应先检查接收流量的网卡或来源属于哪个 zone；流量进入其他 zone 时，仅在面板中修改 public zone 的规则可能无法实现预期效果，参见 已放行端口仍无法访问。

如果 IPv4 正常而 IPv6 显示异常，需单独处理 IPv6；一个 IP 版本正常不代表两个都正常。初始化、恢复等操作提交后，请等待任务完成并查看结果。

#3 主机防火墙

在 iptables、nftables 的默认拒绝模式下，按实际业务需要创建允许规则即可放行相应访问。例如，仅允许办公 IP 访问主机数据库，应将来源设为办公出口 IP、协议设为 TCP、端口设为 3306。未被其他允许规则或端口白名单放行的来源，仍按默认策略拒绝。

#创建访问规则

进入 主机防火墙 → 创建，按需填写：

IP 和端口至少填写一项。需要匹配所有 IPv6 来源时填写 ::/0，并先开启 IPv6 支持。

优先级与规则顺序：

• iptables、nftables、UFW：在编辑规则时调整，数字越小，规则在对应规则链或列表中的位置越靠前；可选范围以页面显示为准。iptables、nftables 的普通规则无法通过此项移到内置保护和端口白名单之前。
• firewalld：后端支持时，可在创建规则或编辑 rich rule 时设置，范围为 -32768 到 32767，数值越小越先匹配。负值先于 zone 的普通放行项，正值后于这些放行项，0 按动作分组处理；同优先级不能用创建先后保证顺序。详见 firewalld 优先级说明。

常见配置：

示例地址需替换为实际地址。允许规则会累加放行范围。 在默认拒绝模式下，如果该端口没有其他放行配置，添加指定来源的允许规则后，仅该来源可以建立新连接。如果端口白名单或已有规则已允许所有来源访问该端口，还需收紧并清理这些宽泛放行配置，才能实现“只允许办公 IP”。

#管理已有规则

可搜索规则，按 IP 版本、动作筛选，并执行编辑、删除或批量删除。内置保护规则不能编辑或删除；白名单规则的访问条件需到 设置 → 端口白名单 修改。

“已使用”表示规则覆盖了正在监听的服务，不代表外部访问一定成功。删除这类放行规则前，请确认不会影响正在使用的服务。

Docker 发布端口可能经过独立的转发路径。若页面提示前往容器端口防护，请在对应页面设置访问限制。

#4 容器端口防护

用于限制 Docker 容器发布到宿主机的端口。主机防火墙的默认拒绝策略不自动覆盖 Docker 独立的转发路径；未配置防护的发布端口保持 Docker 默认访问行为。需要对白名单之外的来源默认拒绝时，选择 仅允许指定来源 并填写允许访问的 IP 或网段。

1. 进入 容器端口防护，按提示初始化并确认已绑定。
2. 找到目标容器，打开 端口详情。
3. 选择一个或多个发布端口，点击 设置。
4. 选择防护模式并填写来源，提交后确认状态为 已生效。

例如，限制 宿主机 3306 → 容器 3306 仅供办公网络使用，应选择对应的 宿主机 3306 发布端口，设置“仅允许指定来源”，填写办公出口 IP 或网段。允许来源仍需满足云安全组等其他访问条件。

使用时注意：

• IPv4、IPv6 的指定来源需分别设置；同时选择两种 IP 版本时，可统一设置“禁止所有访问”。
• 删除防护策略、清空策略或解绑防护，会让相关端口恢复 Docker 默认访问行为。
• 使用 host 网络，或页面提示“该端口由主机直接接收”时，应使用 主机防火墙。
• “未关联规则”表示规则未匹配到当前 Docker 发布端口；确认容器是否已删除、重建或更改端口，再决定是否清理。

#5 端口转发

进入 端口转发，完成初始化后点击 创建规则。

端口支持单个端口和范围，例如 8080-8089。目标 IP 必须与所选 IP 版本一致。

本机转发也可用 127.0.0.1（IPv4）或 ::1（IPv6）表示。该配置采用本机端口重定向，目标服务仍需监听能接收外部重定向流量的地址；仅监听回环地址的服务不应直接视为已可对外访问。

创建后，使用另一台设备访问“本服务器 IP + 源端口”测试。测试前确认云安全组已放行源端口，且目标服务可以访问。本机访问自身地址不一定经过与外部入站相同的转发路径。

IPv6 转发会在添加或恢复 IPv6 规则时检查并按需启用。出现 RA 风险提示时，按 IPv6 RA 风险处理步骤 排查。

#6 设置

#管理方式

可分别选择主机防火墙、端口转发和容器端口防护的管理方式。建议避免多套管理工具同时控制同一类流量。

需要切换时，先导出规则并记录端口白名单等设置；若页面要求重置当前配置，先核对 各后端的重置范围，再选择 备份规则后重置。完成重置后切换、初始化并恢复规则。重置到恢复完成期间，原有防护或转发可能中断，应安排维护时间并保留可用的登录方式。

恢复后检查任务结果和实际访问，不同管理方式间无法转换的规则需按错误提示单独处理。JSON 备份不能替代 UFW、firewalld 的完整配置备份。

切换容器端口防护后端会更新 Docker 配置并重启 Docker，应安排在允许业务中断的时间操作。

#IPv6 支持

此开关控制面板对 IPv6 防火墙规则的管理与生效。关闭后，会隐藏容器 IPv6 端口信息、移除端口白名单配置中的 IPv6 来源，并停用当前所选 iptables、nftables 后端的 1Panel IPv6 规则，相关限制和转发将不再生效。已有规则本身不会因此全部删除；firewalld、UFW 的已有 IPv6 规则也不会被此开关统一停用。

关闭此开关不会关闭服务器的 IPv6 网络。 因此，不应将它作为阻止 IPv6 访问的方式。

重新开启开关不会自动恢复全部防护。 应重新核对并补齐端口白名单中的 IPv6 来源，再分别检查主机防火墙、容器端口防护和端口转发的 IPv6 状态，按提示初始化、绑定或修复。已删除的 IPv6 白名单配置不会自动恢复；完成后从外部重新建立 IPv6 连接验证。

#禁 ping

启用后限制外部 ping 探测。ping 不通不代表网站、SSH 等服务不可用，测试服务时应检查实际业务端口。

#端口白名单

用于补齐并保护指定端口的放行规则，常用于面板、SSH 和其他关键服务。可配置协议、端口和允许来源；来源留空时，按页面提示允许相应 IP 版本的所有来源。

保存时会补齐缺失的放行规则。编辑或删除白名单配置不会自动删除已有放行规则；如果要收紧访问范围，还需检查并清理主机防火墙中的旧规则。

在白名单中填写面板或 SSH 端口不会修改服务的监听端口；服务端口应到对应服务设置中修改。

#7 导入、导出与恢复

各功能页面支持 JSON 规则导入、导出，建议使用对应页面导出的文件。导入前核对 IP、端口、网卡和来源是否适用于当前服务器。

自动备份位于安装基础目录下的 1panel/backup/firewall/，按 host、forward、docker 分类，实际路径以弹窗显示为准。

#备份包含哪些内容

主机 iptables、nftables 的 JSON 导出和自动备份包含普通主机规则，不包含内置保护链中的规则，也不包含 设置 → 端口白名单 的配置。firewalld 的主机规则导出范围为 public zone，不包含整个 firewalld 配置。导出的规则也不等同于管理方式、IPv6、禁 ping 等设置的完整备份。

跨服务器迁移或切换管理方式前，应另行记录这些设置；存在面板管理范围以外的配置时，还需使用对应工具备份，并确认其恢复方式。

#重置范围

备份规则后重置，不等于备份了全部系统防火墙配置。 特别是 UFW、firewalld，恢复 JSON 后仍需检查面板管理范围以外的配置。容器策略被清理后，相关发布端口恢复 Docker 默认访问行为；转发规则被清理后，对应转发中断。

#8 使用注意事项

#8.1 白名单可能先于普通拒绝规则生效

当前 iptables、nftables 主机防火墙先处理内置保护和端口白名单，再处理普通规则。如果白名单已经允许所有来源访问某个端口，后面新增的普通拒绝规则可能无法阻止这些访问。

要收紧权限，应先修改白名单，再检查并清理遗留的宽泛放行规则；不要仅依靠调整普通规则的优先级。

#8.2 禁止访问不会保证立即断开已有连接

主机防火墙的 iptables、nftables 内置规则会先放行已建立和关联的连接，容器防护也会让这类流量先继续交给后续规则处理。因此，新加拒绝规则后，已有 SSH 会话、数据库连接或连接池可能仍可使用。

验证时应断开测试连接，再从外部重新连接。若业务要求立即撤销访问，还需在服务端终止对应会话；不要把清空整机连接跟踪表作为常规操作。

#8.3 容器策略关联的是发布端点

策略按 IP 版本、宿主机绑定地址、宿主机端口、协议 关联，不按容器名称关联。

• 重建容器但保持相同发布端点时，旧策略可能继续匹配；其他容器复用该端点时也需要检查旧策略。
• 修改发布端口，或将绑定地址从 0.0.0.0 改为某个具体 IP 后，应重新检查防护状态。
• 该功能面向宿主机发布端口，不能据此认为容器内部访问、容器之间的直连等路径也已被隔离。

#8.4 转发入口的匹配范围可能比预期更大

当前转发入口按 IP 版本、协议、源端口和可选入站网卡匹配，没有提供“本机目标 IP”或“允许来源”限制。同一网卡配置多个 IP 时，不应认为规则只作用于其中一个 IP；选择全部网卡时，也可能匹配其他网卡进入的同端口流量。

创建前检查与主机服务、Docker 发布端口及其他转发规则是否重叠。需要限定来源或某个本机 IP 时，应在云安全组或实际流量经过的防火墙路径增加对应限制。转发到其他服务器的流量不应仅依靠主机 INPUT 规则限制。

本机转发建议将目标 IP 留空，或使用页面约定的回环地址；不要用本机公网 IP 替代，因为当前程序会将非回环目标按远端目标生成规则。

#8.5 远端转发会改变目标服务看到的来源

当前远端转发同时配置地址伪装（MASQUERADE）。在正常命中这套规则时，目标服务通常看到的是转发服务器的出口地址，而非原始客户端地址，这会影响目标端的 IP 白名单、访问日志和按 IP 限流。地址改写行为见 iptables-extensions 手册中的 MASQUERADE 说明。

如需保留真实客户端地址，当前页面没有关闭来源地址改写的选项，需要另行设计路由或使用目标服务支持的代理方案。防火墙规则也不会读取 HTTP 的 X-Forwarded-For 来识别用户。

#8.6 端口范围不等于逐个端口一一映射

不要把 8000-8009 → 9000-9009 理解为保证 8000 → 9000、8001 → 9001。当前实现将端口范围交给后端 NAT 规则处理，没有生成逐端口对应关系。需要固定对应时，应创建独立的单端口规则。

#8.7 删除转发规则不等于关闭系统转发能力

删除或重置当前转发规则会清理相应规则，但不会自动将系统的 ip_forward、IPv6 forwarding 恢复为关闭。Docker、VPN 等服务也可能依赖这些开关；如需关闭，应先确认其他服务需求。

系统或 Docker 重启、重载，以及通过命令行修改防火墙后，都应复查绑定状态和外部访问。页面的“已生效”表示检测到相应规则和接入状态，不能替代对完整访问路径的测试。

#9 常见问题与排查

#9.1 页面无法操作，或规则未生效

#9.2 已放行端口，仍无法访问

依次检查：

1. 服务是否运行：在目标服务器执行 sudo ss -lntup，确认端口、协议和监听地址正确。仅监听 127.0.0.1 的服务不能直接从外部访问。
2. 外部入口是否放行：检查云安全组、上游路由器及目标服务器的防火墙。
3. IP 版本是否一致：IPv4 规则不覆盖 IPv6。域名有 AAAA 记录时，客户端可能优先使用 IPv6。
4. 规则是否匹配：确认访问者实际出口 IP、协议、端口，以及是否存在先匹配的拒绝规则。
5. 配置入口是否正确：Docker 发布端口按页面提示使用容器端口防护；firewalld 还需检查实际流量所属 zone。

使用 firewalld 时，可执行 sudo firewall-cmd --get-active-zones 查看活动 zone 的网卡和来源绑定，并用 sudo firewall-cmd --get-default-zone 核对默认 zone。若访问流量进入的不是 public zone，应在实际生效的 zone 中维护规则；不要仅为让面板规则生效而直接更改网卡所属 zone。

HTTP 服务可从外部设备分别使用 curl -4 -v http://域名:端口 和 curl -6 -v http://域名:端口 测试；其他服务使用对应客户端建立新连接测试。

#9.3 端口转发不通：检查转发开关与 ACCEPT

先确认目标服务可达、源端口和入站网卡正确，再在转发服务器检查内核转发开关：

sysctl net.ipv4.ip_forward
sysctl net.ipv6.conf.all.forwarding

跨主机转发所用 IP 版本的值应为 1。1Panel 会在启用相应转发时设置；如果值为 0，先查看初始化或添加规则的任务错误。IPv6 出现 RA 提示时，先按下一节处理。

有端口转发规则或 ACCEPT，不代表整条访问路径已经放行。 本机端口重定向需检查主机入站规则中的目标端口；转发到其他服务器则需检查 FORWARD 路径。当前实现会为远端转发创建相应放行规则，但其他管理工具仍可能拦截流量。

按服务器实际安装的组件执行：

# IPv4 的转发策略、规则及命中计数
sudo iptables -S FORWARD
sudo iptables -nvL FORWARD --line-numbers
sudo iptables -t nat -S

# 使用 IPv6 转发时检查
sudo ip6tables -S FORWARD

# 使用 nftables 或存在混合配置时检查
sudo nft list ruleset

重点检查：

• iptables 路径：是否存在提前命中的 DROP / REJECT，是否接入 1PANEL_FORWARD。默认策略为 DROP 本身不一定有问题，需确认目标流量是否先命中了有效的 ACCEPT。
• nftables 路径：某条链的 accept 之后，流量仍可能被其他基础链拒绝；需要检查所有处理转发流量的链。
• 混合环境：使用 nftables 转发时，遗留的 iptables FORWARD DROP 也可能阻断流量，尤其是在 Docker 切换后端后。相关行为见 Docker 官方说明。

优先在实际拦截流量的管理工具中，为所需来源、目标和端口配置转发放行及回程规则。如果确认问题仅是旧的 iptables 默认 DROP，且转发访问已由当前规则完整控制，可将对应 IP 版本的默认策略改为 ACCEPT：

# 仅在上述条件满足时执行；不要作为通用修复命令直接套用
sudo iptables -P FORWARD ACCEPT
# 仅需要处理 IPv6 时执行
sudo ip6tables -P FORWARD ACCEPT

这会扩大未匹配规则的转发流量可通过范围，也不会覆盖已有的显式 DROP。修改前记录原策略；无效时恢复原值，并继续定位拦截规则。确认有效后通过实际管理工具保存配置，避免重启后被覆盖。

#9.4 IPv6 转发提示 RA 断网风险

现象：提示“IPv6 转发存在断网风险，已阻止启用”。

部分服务器通过路由器通告（RA）获取 IPv6 路由或通过 SLAAC 配置地址。网卡的 accept_ra=1 表示仅在未启用转发时接收 RA；启用转发后可能导致地址或默认路由无法续期。1Panel 检测到这种风险会阻止启用。accept_ra=2 表示开启转发后仍接收 RA，见 Linux 内核参数说明。

处理步骤：

1. 查看 1Panel 系统日志，找到 IPv6 forwarding blocked，确认提示涉及哪些网卡。
2. 检查实际 IPv6 地址、默认路由和对应网卡配置。以下 eth0 需替换为日志中的实际网卡名。

ip -6 addr show
ip -6 route show default
sysctl net.ipv6.conf.eth0.accept_ra
sysctl net.ipv6.conf.all.forwarding

3. 确认该网卡确实需要接收 RA 后，将该网卡设为 2：

sudo sysctl -w net.ipv6.conf.eth0.accept_ra=2

4. 将设置持久化。例如编辑 /etc/sysctl.d/99-1panel-ipv6-ra.conf，加入下列内容，再加载该文件：

net.ipv6.conf.eth0.accept_ra = 2

sudo sysctl -p /etc/sysctl.d/99-1panel-ipv6-ra.conf

5. 返回面板重试，确认任务成功，复查 IPv6 地址、默认路由及外部访问。若由 NetworkManager、systemd-networkd 等管理网卡，也需确认其配置不会覆盖该设置。

不要仅修改 all.accept_ra 后就认为每张网卡都已生效，应逐个核对日志提示的接口。静态 IPv6 环境应先核对地址和路由配置；只有链路本地地址时也不能直接认定不需要 RA。

若提示“无法检查 IPv6 网络配置”，应检查日志中读取 /proc、网络信息或命令执行失败的原因，修复后重试，不要直接跳过检查强行开启转发。修改远程服务器网络参数时，保留可用的 IPv4 SSH 或云控制台连接。

#9.5 容器防护未生效，或容器端口无法访问

调整防护后，请从外部设备重新建立连接测试；已有连接可能受连接跟踪影响，不能单独用来判断新策略是否生效。

#9.6 修改后无法访问面板或 SSH

通过保留的 SSH 会话或云控制台登录，检查实际服务端口、允许来源和规则顺序，恢复所需放行规则。恢复访问后，在 端口白名单 中修正配置，并检查是否有旧的放行或拒绝规则遗留。

仍无法解决时，提供失败时间、功能页面截图、任务日志、所用管理方式、IP 版本，以及“访问来源 → 本机端口 → 目标地址和端口”，便于定位。