防墙怎么选择：先分清封锁、配置还是网络，再定入口架构

防墙怎么选择：先判断失效类型，再决定投入在哪一层

防墙怎么选择，核心不是挑一个“最难被封”的协议。应先弄清节点是怎么失效的，再决定投入在哪一层。如果只是个别节点偶发断连，多数是配置或线路质量问题，调整协议参数、证书和端口通常就能处理。如果同一入口换 IP 后几天内再次不可用，说明问题出在暴露面本身，单纯换协议意义有限。这时应优先考虑入口与后端分离，以及多入口切换。

选择时可以按三个维度排序。一是隐蔽性，即流量特征是否接近正常 TLS 访问。VLESS+Reality、Trojan、基于 WebSocket 或 gRPC 的 TLS 转发各有取舍，没有哪一种能完全规避识别。二是暴露面，即用户订阅里是否直接暴露落地或源站 IP。三是可替换性，即入口失效后能否不改动后端就快速切换。对机场运营者来说，后两项往往比协议本身更影响整体稳定性，协议选型只是第一步。

区分封锁、配置与网络问题

动手换方案前，先把“被封”和“没配好”分开，否则容易在错误方向上反复换 IP。可以按现象对应判断：

看到所有地区、所有运营商都连不上，服务器本机 curl 正常、日志里没有新连接 → 多为服务端监听、防火墙或安全组问题 → 用 ss -tlnp 确认端口在监听，再核对云厂商入站规则。 看到海外探测正常，国内能 ping 通，但 TCP 443 握手超时或被重置 → 较可能是端口或 IP 受到干扰 → 换一个端口对比测试，判断是单端口受影响还是整个 IP 不可达。 看到只有部分运营商或晚高峰丢包、延迟飙升，白天恢复 → 偏向线路拥塞 → 用 mtr 观察丢包从哪一跳开始。 看到客户端日志反复出现 tls handshake failure 或 x509 证书错误 → 优先检查 SNI、证书域名和设备时间。

判断原则是：同一时间段内，用国内多个运营商和海外各测一次。只有“海外通、国内全断、本机正常”同时成立，才比较有把握归为封锁。

DNS / SNI / TLS / 客户端 / 服务端单节点排查

单节点排查建议按以下顺序进行，每一步确认正常后再往下：

1. DNS：在国内执行 dig +short node.example.com，与海外解析结果对比。若返回异常 IP 或没有结果，说明解析被污染或记录尚未生效。 2. 端口连通：执行 nc -vz 203.0.113.10 443 或 tcping。timeout 和 refused 含义不同：refused 通常表示服务没有监听，timeout 更可能是链路被丢弃。 3. TLS 与 SNI：执行 openssl s_client -connect 203.0.113.10:443 -servername node.example.com，检查证书链和域名是否匹配。如果使用 Reality，则核对 serverNames 与目标站点在服务器上能否正常访问。 4. 客户端：确认订阅已更新，UUID、传输类型、path 与服务端一致，并校准设备时间。 5. 服务端：执行 journalctl -u xray -n 100，看是否有对应的入站记录，再检查防火墙和带宽占用。

如果五步都正常，却只在国内失效，就进入入口、中转、落地分层定位。

验证：选定方案后如何确认真的有效

选定方案后，不要只看"能连上"就推广，建议至少观察 24-72 小时，按以下步骤验证：1. 在入口机执行 ss -tlnp | grep 443，确认监听端口和进程正确；2. 从不同运营商网络执行 curl -v --resolve example.com:443:入口IP https://example.com/，看 TLS 握手是否完成，证书和 SNI 是否与配置一致；3. 分别对入口、中转、落地执行 nc -vz IP 端口，逐层确认连通；4. 在 Xray 或 sing-box 日志中统计 i/o timeout、connection reset by peer、TLS handshake error 出现的时段和比例。

判断逻辑可以这样走：握手在入口就超时，多半是入口 IP 或端口受干扰，先换入口或端口对照验证。入口握手正常而落地超时，问题在中转或落地链路，应检查转发规则和落地防火墙。只有部分运营商失败，更像线路质量或区域性干扰，而不是配置错误。验证通过后再分批替换节点，不要一次改完全部线路。

失败边界：哪些情况单纯换方案解决不了

自助调整能解决的，通常是单节点问题：伪装参数写错、证书过期、端口冲突、客户端版本过旧。以下几种情况，只换协议或换端口往往效果有限。一是入口 IP 所在网段整体被限速或丢包，换到同段 IP 后很快复现。二是源站 IP 已经通过订阅、面板域名或历史 DNS 记录暴露，新入口刚上线就被关联。三是落地 IP 被目标网站风控，表现为节点能连但网站打不开或频繁弹验证，这和防墙无关。四是用户侧网络本身受限，例如校园网或企业网关做了 SNI 过滤。

所以要先划清边界。同一时间只有个别节点失败，修配置即可。换 IP 后几天内多个入口相继失效，或者故障总集中在高峰期，就说明问题已经超出单节点选择，再换一次协议通常只是把问题推迟。也不存在能长期免受干扰的单一协议，任何选择都应预留替换路径。

长期架构：入口、转发与后端解耦及服务适用边界

长期更稳的思路，是把入口、转发与后端分层解耦。入口层用多个 IP、多条线路承接用户连接，通过短 TTL 的 DNS 或订阅中的多入口实现切换。中转层负责把流量转到落地，单个中转失效时只需调整转发目标，用户订阅不必变化。落地层只接受来自中转的连接，用防火墙白名单隐藏源站，降低源站暴露风险。面板如果用 XBoard/V2Board，节点地址应指向入口而不是落地 IP，换入口时只改节点记录。再对各层做定时探测，就能在用户大量反馈之前发现异常。

如果只是单个节点配置问题，按前文自行排查即可。如果多个入口或中转频繁失效，换 IP 后短期内反复出问题，或者需要明确区分入口、中转与落地故障并设计切换方案，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/）。该方案侧重链路规划、多线路部署与故障排查，实施范围需要先结合你的现有架构沟通确认。

什么时候这已经不是单点配置问题

如果按上面的步骤排查后发现，失效不是某个节点的配置问题，而是多个入口或中转反复失效、换 IP 后很快复发，或者分不清是入口、中转还是落地出了问题，就可以参考 Manguo Labs 的机场高可用入口方案，先做分层诊断，再设计切换。

Manguo Labs 能提供什么

Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。

本文的读者是机场运营者，关心的是节点失效后如何定位、如何选择防墙架构。Manguo Labs 的机场高可用入口解决方案正好覆盖入口、中转与落地链路的高可用规划和故障排查，适合问题已经超出单节点配置的场景。

适合这些情况

• 多个入口或中转频繁失效
• 换 IP 后短期内反复出现失效
• 需要区分入口、中转与落地故障并设计切换方案
• 使用 XBoard/V2Board，需要多线路批量部署与客户端排查

查看机场高可用入口解决方案 →

常见问题

总结与下一步

防墙怎么选择取决于故障发生在哪一层：先区分封锁、配置和网络问题，再按 DNS、SNI、TLS、客户端、服务端逐项排查，并定位到入口、中转或落地。单点问题可以修配置或换 IP 临时处理。如果入口反复失效，应采用入口、转发、后端解耦的多线路架构，减少源站暴露，并预先设计切换流程。没有哪种方案能保证永远可用，目标是降低失效频率、缩短恢复时间。

需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。