SSH 还连得上，但启用宿主机防火墙后，Web 管理界面突然打不开；也可能两边都失联。
适合：先固定管理端实际来源地址，分别放行 SSH 与 Web 入口，再启用限制策略；用第二条独立会话确认规则生效。不适合：没有带外控制台或其他恢复通道，却要远程改动唯一管理入口的策略。
正在为独享服务器上的 PVE 宿主机限制 SSH 来源的管理员，可按本文规划规则与验证顺序。
负责远程维护的 MSP，可用检查清单控制变更风险并设定回退条件。
需要开放公网管理入口的企业 IT，可借此区分宿主机管理规则与 VM、容器业务规则。
先划清管理入口的边界
本文处理的是 PVE 宿主机本身的管理流量，不是 VM 或 LXC 容器内应用的访问策略。宿主机 SSH 与 Web 管理入口是两项服务：官方管理指南给出的 Web 界面入口为 TCP 8006，SSH 通常使用 TCP 22。防火墙规则需要分别匹配对应端口；只放行其中一个，并不会自动开放另一个。(pve.proxmox.com)
先记录当前访问方式：管理端是固定公网地址、经 NAT 转换的地址，还是通过 VPN 到达宿主机？如果客户端处在公司出口、VPN 网关或其他转发设备之后，宿主机看到的来源地址可能是转换后的地址，而非管理员电脑的本地地址。规则里的来源范围应以实际抵达宿主机的地址为准。
| 管理需求 | 规则规划 | 验收方式 |
|---|---|---|
| SSH 管理 | 允许管理来源访问 TCP 22 | 从另一个终端建立新的 SSH 会话 |
| Web 管理 | 允许管理来源访问 TCP 8006 | 用新浏览器会话打开 PVE 管理地址 |
| 管理来源不固定 | 暂不按单个地址收紧；先确认稳定的管理路径或恢复通道 | 从不同出口分别验证，未验证前不切换到拒绝策略 |
| VM / 容器业务访问 | 在对应 VM 或容器防火墙层规划，不与宿主机管理规则混为一谈 | 从业务实际入口测试应用端口 |
PVE 官方防火墙文档分别描述宿主机、虚拟机和容器等规则适用范围。宿主机允许 SSH 或 Web 管理访问，不代表 VM 内的业务端口也已获得保护；反过来，VM 的规则也不能替代宿主机管理入口规则。(github.com)
按实际来源准备独立规则
在 PVE 防火墙远程管理中，容易造成误锁的不是“规则条数不够”，而是来源地址选错、规则没有应用到目标层级，或只为一个管理入口写了允许规则。先在管理端确认当前公网出口地址，再从服务器侧可用的现有会话或已知网络信息核对宿主机看到的来源；若来源会变化，应先解决管理地址稳定性，而不是猜测一个较宽的网段后立刻启用拒绝策略。
只允许指定 IP 管理时，分别为 SSH 和 Web 管理入口建立允许规则，来源填已核实的地址或受控网段，协议选 TCP，目标端口分别填 22 与 8006。然后检查规则所处的 Datacenter 或节点层级、方向、启用状态与匹配顺序；具体界面字段和规则行为应以当前安装的 PVE 9.x 官方防火墙文档为准。(github.com)
远程改规则前的勾选清单
没有可用控制台时，能不能远程改 PVE 防火墙？可以先准备并验证规则，但如果没有带外控制台、可信的现场人员或其他已确认的恢复通道，不应远程执行可能切断唯一管理入口的变更。2026 年 8 月 3 日的社区帖子记录了 SSH 与 Web 管理同时不可达的个案，但讨论中也涉及网络接口和地址冲突等排查方向；它不是防火墙必然导致失联的证据。(forum.proxmox.com)
依次完成下列检查；任何关键项无法确认，就暂停收紧策略：
- [ ] 记录当前 SSH 与 Web 管理入口的访问地址、客户端出口地址和经过的 NAT／VPN 路径。
- [ ] 核实宿主机实际看到的来源地址，并确认该地址或网段在变更期间不会改变。
- [ ] 分别准备 TCP 22 与 TCP 8006 的允许规则，确认来源、方向、应用范围及启用状态。
- [ ] 保存现有防火墙配置副本，并确认如何在不依赖即将被限制的连接时恢复。
- [ ] 保持现有管理会话，不关闭、不退出，也不把它当作唯一验收连接。
- [ ] 应用规则后，用另一台设备或另一条独立连接分别测试 SSH 与 Web 管理界面。
- [ ] 两种入口都验证成功后，再分阶段收紧默认策略；每次只改变一项，并立即重复验收。
这一顺序比“先把默认策略改成拒绝，再补允许规则”更稳妥，因为后者可能在规则遗漏或来源判断错误时立即切断远程访问。远程验证必须是新连接：旧 SSH 会话仍存活，不足以证明新的 SSH 连接已获准；浏览器中已有页面仍能显示，也不足以证明新建的 Web 会话能到达管理服务。
SSH 通而 Web 不通时分层排查
SSH 可用、Web 管理界面打不开时怎么办？先不要改动 SSH 的有效规则，也不要直接关闭全部防护。按下面顺序检查，尽量利用现存 SSH 会话读取状态：
- 从当前管理端确认访问的是宿主机地址，并检查浏览器使用的协议和端口是否为 HTTPS 与 TCP 8006。
- 在 PVE 防火墙规则中核对 Web 入口对应的允许项：来源是否是宿主机实际看到的地址，目标端口、方向、规则层级和启用状态是否正确。
- 若规则看起来匹配，再检查宿主机的 Web 管理服务状态及其监听情况；官方管理指南与防火墙文档可用于核对管理入口和规则行为，不要把社区个案里的处置方法直接当作通用修复。(pve.proxmox.com)
- 如果服务正常监听但连接仍失败，继续核对客户端到宿主机的网络路径、上游访问控制和地址转换；如果 SSH、Web 都不通，且宿主机仍可响应其他网络探测，也不能据此断定是防火墙故障。
2026 年社区中确有用户报告防火墙规则与 IPv6 下 SSH、Web 访问异常的个案；它只能提示排查时不要忽略地址族、接口及规则匹配，不能证明 PVE 9.2 存在普遍故障。(reddit.com)
SSH 和 Web 都失联时保留回退路径
开防火墙后 SSH 连不上怎么办？如果 Web 入口也不可达，先从已准备好的独立恢复通道进入宿主机，再检查来源地址、规则层级、匹配顺序、网络接口路径，以及 SSH 和 Web 管理服务状态。若没有任何恢复通道，就不能依靠 SSH 命令远程修复一条已经阻断 SSH 的规则；应联系服务器服务方确认实际可用的恢复方式，而不是假设它提供带外控制台或远程 KVM。
若只剩一个入口可用，先通过该入口核对规则和服务状态，再决定是否回退最近一次防火墙变更。不要在原因不明时直接清空防火墙规则，或把所有流量临时改为放行：这会扩大暴露面，也可能掩盖网络路径、服务状态或来源地址方面的问题。Proxmox 社区曾记录过“管理界面被拒绝策略挡住”的个案，但个案不能替代针对当前 PVE 9.x 配置的官方文档核对。(forum.proxmox.com)
把公网管理面与 VM 业务面分开
宿主机的 SSH、Web 管理界面只应对实际需要的管理来源开放；VM 或容器承载的业务端口，则应按各自网络路径和应用需求另行设计。不要为了让一台 VM 对外提供业务服务，就把宿主机的管理入口也对所有公网来源开放。若一台服务器承载多个租户或多组服务，宿主机规则、VM／容器规则及上游网络控制各自保护的对象不同，需要分别验收。
独享服务器与共享主机的差异，也不等于防火墙会自动替管理员完成安全配置：共享 VPS 的宿主机策略可能不由租户控制；公有云实例的访问控制还可能分布在实例内与平台侧；独享物理机则把宿主机管理规则和 VM 网络规划更多交给使用者自行负责。若业务只需短时运行、负载很轻，或需要按秒弹性伸缩，物理机未必合适；若要长期运行多台 VM，并希望自行控制宿主机规则与资源，独享 AMD 物理机更值得比较。
准备部署时，可在 XFP Cloud 的服务器配置页面核对页面实际列出的 Proxmox 系统选项，并通过 付款后的接入说明确认已列明的远程接入方式；不要把未写明的恢复能力当作保障。若当前方案受共享 CPU、宿主机防火墙权限或长期资源控制限制，XFP Cloud 的独享 AMD 物理机更适合需要自行管理 PVE 宿主机、持续运行多台虚拟机的场景。部署前先确认管理来源与恢复路径，再对照单公网 IP 下的虚拟机联网方案规划 VM 网络；防火墙规则出错时，XFP Cloud 是否能提供特定恢复操作，应以实际说明和工单答复为准。
最后更新于 2026 年 10 月 27 日，版本日期核实自 Proxmox 官方发布信息；规则与入口核对自 Proxmox VE 9.x 官方管理指南及防火墙文档。Proxmox VE 9.2 于 2026 年 5 月 21 日发布。(proxmox.com)