防墙怎么做：先给结论
防墙不靠找一个“不会被墙”的协议，而是要降低入口被识别、被批量封锁的概率，并在某个入口失效时能快速判断、快速切换。对机场运营者来说，比较务实的顺序有三步。第一步，确认故障到底是封锁、配置错误还是线路质量问题。第二步，把暴露在用户侧的入口和真正承载流量的中转、落地分开。第三步，为入口准备可替换的冗余和持续监控。
单纯换 IP 只能解决眼前的问题。如果源站 IP 直接写在订阅里，所有用户都连同一个地址，证书和 SNI 又长期不变，新 IP 往往很快重复同样的结局。所以“防墙”更准确的目标是两点：一是缩小暴露面，二是缩短恢复时间。入口可以随时替换，后端不受牵连，用户订阅也能平滑更新。下面先讲如何判断，再给出单节点的排查步骤。
区分封锁、配置与网络问题
很多看起来像“被墙”的情况，其实是配置或线路问题。误判的代价是白白换掉一个本来能用的 IP。可以按现象粗分：
- 国内多地 ping 不通、TCP 443 超时，海外探测正常：大概率是 IP 层封锁。下一步用 tcping 或 mtr 在国内外两侧对比确认。 - 端口能连通，但 TLS 握手失败或握手后立即被重置：可能是 SNI 或流量特征被干扰，也可能是证书过期、解析错误。下一步在海外用 openssl 自测证书链，排除自身问题。 - 国内外都连不上：优先怀疑服务端进程、本机防火墙或云厂商安全组，而不是封锁。 - 能连上但晚高峰丢包高、速度骤降：多为线路拥塞，换路由或加中转通常比换 IP 有效。
另一个关键信号是影响范围。只有单个节点异常，多是单点问题。如果同一机房多台机器、同一批新 IP 先后失效，就要回头检查暴露方式本身。
DNS、SNI、TLS 与客户端服务端的单节点排查
单节点异常时，建议按以下顺序逐项排除： 1. 服务端自检。执行 systemctl status xray（或 sing-box），用 ss -lntp | grep 443 确认端口在监听，再用 journalctl -u xray -n 50 查看是否有证书或配置报错。 2. 防火墙与安全组。检查 ufw status 或 iptables -L -n 的输出，同时确认云厂商控制台的安全组已放行对应端口。 3. DNS。在国内和海外分别执行 dig +short node.example.com。如果两边结果不一致或指向异常地址，说明可能存在解析污染或记录尚未生效。 4. TLS 与 SNI。在海外机器执行 openssl s_client -connect 服务器IP:443 -servername node.example.com，确认证书域名和有效期。国内执行同一命令卡住而海外正常，说明问题指向链路干扰。 5. 客户端。核对订阅里的地址、端口、UUID、传输方式和 SNI 是否与服务端一致。日志出现 context deadline exceeded，多为连接不上；
出现 tls: handshake failure，多为证书或 SNI 不匹配。 五步都做完仍找不到单点原因，就应进入入口、中转、落地的分层定位。
调整后怎么验证：多运营商、多时段和真实流量
换 SNI、换入口 IP 或调整中转之后，不能只看自己这一条宽带能不能连上。至少要从电信、联通、移动三类网络分别测试，并覆盖晚间 20:00–23:00 高峰时段。建议连续观察 24–72 小时再下结论。基础检查可以按这个顺序做：`mtr -rwc 50 入口IP` 看丢包出现在哪一跳；`openssl s_client -connect 入口IP:443 -servername 你的域名` 看 TLS 握手能否完成、证书是否正确；最后在客户端本地执行 `curl -x socks5h://127.0.0.1:7890 -o /dev/null -w "%{http_code}\n" https://www.gstatic.com/generate_204`，返回 204 才算真实流量走通。
判断逻辑如下。如果 TCP 能建立但 TLS 卡住，同时服务端 access log 里没有对应请求，问题出在 SNI、证书或协议特征，回头查 TLS 配置。如果只有某一家运营商全部超时，其他运营商正常，那是入口线路问题，需要为这家运营商单独准备入口。如果三网都通但高峰期大量超时，优先查中转带宽和落地负载，而不是继续换 IP。
失败边界：哪些情况靠自助调整解决不了
自助排查适合处理单节点问题，比如证书过期、端口被占用、时间不同步导致握手失败、客户端配置写错。有几类现象说明问题已经超出单节点配置的范围。第一类是换了新 IP 之后，短期内又以同样方式失效，说明暴露的是入口的发现方式，而不是哪一个 IP。第二类是落地机直接对用户开放，和入口用的是同一个 IP，一旦被识别，整条链路都要重建。第三类是订阅地址或节点信息外泄，新入口刚上线就出现大量陌生探测连接，服务端日志能看到非用户来源的异常握手。第四类是中转线路本身质量不稳，表现为多个入口同时变差。
遇到这些现象时，正确的下一步是停止反复换 IP。每次换 IP 都有成本，问题却没有变化。应该把精力转到入口暴露面、链路分层和切换机制上。所谓防墙，靠的不是某个“不会被封”的配置，而是降低被识别的概率，并让单点失效时可以快速替换。任何承诺不会被封的说法都不可信。
长期架构，以及什么时候需要外部方案
长期思路是让入口、转发、后端三层解耦。入口层按运营商分组，每组准备多个可替换入口，通过域名或订阅分组下发，替换入口时不需要改动后端。中转层负责线路质量，和入口分开监控。落地层只接受中转来源的连接，用防火墙白名单关闭公网直连，减少源站暴露。面板侧（如 XBoard/V2Board）配合健康检查，按分组更新节点，让失效入口尽快从订阅里下线。
如果你的问题只是单节点配置，按前文步骤自查通常就够了。如果已经出现多个入口或中转频繁失效、换 IP 后短期内复发，或者需要明确区分入口、中转、落地的故障并设计切换方案，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/）。这套方案覆盖入口、中转与落地链路的高可用规划和故障排查，包括降低源站暴露风险、多线路批量部署、XBoard/V2Board 对接，以及客户端检查。具体是否适用，建议先带上现有架构和日志现象，通过产品页或 Telegram 沟通评估。
什么时候这已经不是单点配置问题
如果按上面的步骤排查后，确认问题不在某一个节点的配置，而是入口、中转、落地反复失效，或者每次换 IP 都撑不了多久，单靠手动处理成本会越来越高。这时可以参考成熟的高可用入口方案，先评估��有链路，再决定怎么改造。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
Manguo Labs 的机场高可用入口解决方案面向机场运营者，提供入口、中转与落地链路的高可用规划和故障排查，适合多个入口或中转频繁失效、换 IP 后短期内又出问题、需要分清各层故障并设计切换方案的场景。方案也涉及降低源站暴露风险、多线路批量部署、XBoard/V2Board 节点下发，以及客户端检查。
适合这些情况
- 多个入口或中转频繁失效，手动更换跟不上
- 换 IP 后短期内反复失效，怀疑源站已经暴露
- 需要分清入口、中转与落地的故障，并设计自动或半自动的切换方案
- 基于 XBoard/V2Board 运营，需要多线路批量部署和节点信息统一管理
常见问题
怎么判断节点是被墙了，还是配置出错？
在境外机器上用同样的客户端配置去连：境外能通、境内不通，大概率是封锁或线路问题；境外也不通，先查服务端配置、证书和端口监听。境内可以 ping 通但 TCP 443 握手超时，多半是端口或 IP 被封；完全 ping 不通又不是禁 ICMP 的情况，可能整个 IP 都被封了。
换 IP 后几天又失效，正常吗？
如果源站 IP 暴露在订阅里，或者同一批 IP 段、同一种协议特征被反复使用，换 IP 只能撑一阵子。这说明问题出在架构层，不是单个节点配置，应当考虑把入口和后端分开，并准备多条可切换的线路。
TLS 或 SNI 配置错了会表现得像被墙吗？
会。证书过期、SNI 跟证书域名对不上、ALPN 不一致，都会导致握手失败，客户端日志里常见 tls handshake failure 或 EOF。可以先用 openssl s_client -connect 域名:443 -servername 域名 检查证书链和返回的域名，排除配置问题后再判断是不是封锁。
中转机正常但落地不通，应该先查哪里？
在中转机上直接用 curl 或 nc 测试落地端口。中转到落地不通，就查落地防火墙、服务进程和线路质量；中转到落地正常、用户端还是不通，就回头查转发规则和端口映射。
XBoard/V2Board 面板跟节点可用性有关系吗？
面板本身不负责防墙，但它决定了订阅里下发什么地址。如果订阅直接暴露源站 IP，后端容易被一起封掉。规划高可用时，要让面板下发的是入口或中转地址，并能批量切换节点信息。
总结与下一步
防墙怎么做，关键在于先判断再动手：用境内外对照测试、DNS/SNI/TLS 检查和客户端日志，把封锁、配置和网络问题分开；再按入口、中转、落地分层定位。换 IP、换端口只能临时救急。如果问题反复出现，就要做入口、转发、后端解耦的多线路架构，降低源站暴露风险。整个过程不可能做到完全不被封锁，目标是缩短故障时间、做到可以快速切换。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →