节点连不上，先别急着下“被墙”结论
节点突然无法连接时，很多运营者第一反应是 IP 被墙，直接换 IP 或换机器。实际上，相当一部分“被墙”属于误判：证书过期、服务端进程崩溃、云厂商安全组改动、系统时间漂移、域名解析异常、客户端订阅配置错误，都会表现为“连不上”“超时”“握手失败”，和封锁的现象高度相似。如果没有确认原因就更换 IP，原来的故障在新 IP 上会照样出现，还会白白消耗资源。
判断是否真的被墙，核心是做对照：同一个 IP 和端口，从境外网络访问正常，从国内多个运营商访问都失败，并且服务端进程、证书、时间、监听端口都确认正常，这时才比较接近封锁。反过来，如果境外也连不上，或者只有某一个客户端、某一个运营商异常，问题大概率在配置、服务端或链路本身。先排除这些低成本因素，再讨论封锁和架构调整，判断会准确很多。
区分封锁、配置与网络问题：按现象做判断
可以用“看到 A → 判断 B → 下一步 C”的方式快速分流。境外 VPS 用 curl 或 nc 测试也失败 → 问题在服务端本身，不是封锁 → 先查进程状态、监听端口和防火墙。境外正常、国内全部运营商 ping 和 TCP 都不通 → 可能是 IP 级封锁 → 再换端口和协议做对照确认。国内能 ping 通但指定端口 TCP 不通，换端口后恢复 → 更像端口级干扰，或者本地防火墙规则写错了。
TCP 能连通，但 TLS 握手失败或客户端报证书错误 → 优先检查证书有效期、SNI 和域名是否一致，这类问题通常不是封锁。只有部分用户异常 → 先对比这些用户的运营商、客户端版本和订阅内容。VMess 节点报认证失败 → 检查服务端和客户端的时间差，一般要在 90 秒以内，超过就会被拒绝。
另外要留意时间特征：如果每次异常都出现在高峰时段、过后自行恢复，更可能是线路拥塞或丢包，而不是被墙。封锁通常表现为持续性的不可达。
单节点排查：DNS、SNI、TLS、客户端与服务端逐项确认
建议按以下顺序排查，每一步只验证一个变量： 1. 服务端状态：执行 systemctl status xray 和 journalctl -u xray -n 50，确认进程在运行、日志里没有配置解析错误；再用 ss -tlnp | grep 443 确认端口确实在监听。 2. 防火墙与安全组：检查 ufw status 或 iptables -L -n，同时到云控制台核对安全组入站规则有没有被改动。 3. 时间同步：执行 timedatectl，确认 NTP 已同步。 4. DNS：分别执行 dig 域名 @223.5.5.5 和 dig 域名 @1.1.1.1。结果不一致或返回异常 IP，说明解析层存在问题。 5. TLS 与 SNI：执行 openssl s_client -connect IP:443 -servername 域名，查看证书链和有效期；用 openssl x509 -enddate 可以单独确认到期时间。 6. 国内外对照：在境外机器和国内多个运营商网络分别执行 nc -zv IP 443，并记录结果。
7. 客户端：重新拉取订阅，核对地址、端口、UUID、传输方式和 SNI 字段，必要时换一个客户端交叉验证。 只有前五项全部正常、第六项呈现“境外通、国内全断”，才把问题归入封锁处理。
修复后的覆盖验证：用多地区、多运营商交叉确认
改完配置或换入口后，只在一台电脑上连通，还不能排除被墙误判。至少要从三个视角复测：国内不同运营商的探测点、境外服务器本机、真实用户客户端。在入口机上运行 nc -vz 入口IP 端口，确认端口确实在监听；在国内探测点上运行 openssl s_client -connect 入口IP:443 -servername 你的SNI，确认握手能完成并返回正确证书；再运行 curl -v --resolve 域名:443:入口IP https://域名/，检查 HTTP 层是否正常。
判断方法如下。境外通、国内全部超时，基本可以判断是入口受限，下一步换入口或启用备用入口。只有某一个运营商不通、mtr 在骨干段大量丢包，更像线路质量问题，下一步调整中转线路。握手报 certificate verify failed 或 SNI 不匹配，是证书或配置问题，下一步检查证书链和客户端里的 servername。复测要间隔数小时做两轮以上，单次结果不能作为结论。
失败边界：自助排查什么时候不够用
自助方法适合定位单个节点的问题，比如证书过期、端口没放行、客户端协议参数写错、DNS 解析到了旧 IP。遇到下面几种情况，继续逐台排查的收益会很低。
第一种：新换的 IP 在几天甚至几小时内又失效，而且多个入口先后出现相同的握手超时。这通常说明暴露方式本身有问题，不是某台机器配错了。第二种：入口、中转、落地混在同一批服务器上，日志里看不出请求停在哪一层，只能整体重启碰运气。第三种：订阅里所有节点共用同一个入口域名或同一组 IP，一处受限就全部受影响。第四种：面板显示节点在线，但用户侧大面积报告连接失败，监控结果和真实体验对不上。
出现这些信号时，就不该再把问题简单归为被墙或没被墙。更合适的做法是记录失效时间、受影响运营商和对应层级，为调整架构准备证据。换 IP 只能临时缓解，无法保证不再失效。
长期架构与服务适用边界
长期思路是把入口、转发、后端拆开。入口层只负责接入，数量多、可替换，并且不直接暴露落地或面板源站。中转层负责线路选择，可以按运营商分组。落地层只接受来自中转的流量，不对公网开放业务端口。拆开之后，某个入口失效时只需替换这一层；同时配合分层探测，就能判断故障出在入口、中转还是落地，减少被墙误判。订阅侧要按入口分组下发，避免所有节点绑在同一个域名上。
如果你已经遇到多个入口或中转频繁失效、换 IP 后很快复发，或者需要设计分层切换方案，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/）。这套方案提供入口、中转与落地链路的高可用规划和故障排查，也可以通过 Telegram（https://t.me/ManguoShop_bot）先沟通现状。如果只是单节点配置错误，按前文步骤自行修复即可，不需要引入额外方案。任何架构调整都只能降低风险，不能承诺节点不会受限。
什么时候这已经不是单点配置问题
如果按上面的步骤排查后，问题只出在单个节点配置上，自己修复就可以了。如果多个入口或中转反复失效，换 IP 后很快又出现同样的问题，或者团队很难分清是哪一层出的故障，可以考虑系统地规划入口、转发与后端的解耦和切换方案。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
本文的排查逻辑和 Manguo Labs 机场高可用入口解决方案相对应：这个方案为机场运营者做入口、中转与落地链路的高可用规划和故障排查，能处理多个入口或中转频繁失效、换 IP 后短期内又失效的情况，也能帮助区分入口、中转与落地故障并设计切换方案。
适合这些情况
- 多个入口或中转频繁失效，难以判断是否真被封锁
- 换 IP 后短期内反复出现同样的失效
- 需要区分入口、中转与落地故障并设计切换方案
常见问题
境内 ping 不通，是不是就能确定被墙了？
不能。很多云厂商和防火墙默认禁 ICMP，ping 不通很正常。应该用 tcping 或 nc -vz IP 端口测试 TCP 端口，并在境外机器上做对比。境外端口通、境内多个地区和运营商都不通，才比较可能是封锁；只有单一运营商异常，也可能是线路问题。
日志里出现 TLS handshake timeout，是被墙还是配置错误？
两种都可能。先在服务器本机执行 openssl s_client -connect 127.0.0.1:443 -servername 你的域名，检查证书和握手；本机握手失败，就是证书、SNI 或服务配置的问题。本机正常、境外正常、只有境内超时，再考虑 SNI 或 IP 层面的干扰。
换了 IP 马上就能用，说明原来那个 IP 确实被墙了吗？
可能性比较大，但不能完全确定。换 IP 往往会同时换掉路由和解析缓存。如果新 IP 几天内又失效，说明问题不在单个 IP，而是暴露方式或架构本身，比如入口直接暴露源站、订阅泄露了真实地址。这时候继续换 IP 只能暂时缓解。
中转节点正常，用户却连不上，怎么定位？
分段测试：用户到入口、入口到中转、中转到落地，在每一段的上游机器上用 nc 或 curl 测下一跳端口，同时看各层服务日志里有没有对应连接记录。连接只到入口为止，就查转发规则；连接到了落地却没有返回，就查落地出口和防火墙。
总结与下一步
被墙误判的常见原因是只看“境内连不上”这一个现象。正确做法：先用境外探测排除配置和服务问题，再按 DNS、SNI/TLS、客户端、服务端逐项检查，然后在入口、中转、落地之间分段定位。单节点问题自己修复就行；如果多个入口反复失效、换 IP 后很快又出问题，就需要把入口、转发和后端拆开，配合多线路和切换方案来降低源站暴露风险。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →