节点被墙怎么判断：先确认现象，再决定处理方式
节点被墙时，最常见的表现是：国内客户端连接入口 IP 时 TCP 超时，ping 也不通；境外探测到同一个 IP 和端口却正常；多个用户、多个运营商几乎同时失效。换端口或换 IP 后可能短暂恢复，但过几天又会失效。遇到这种情况，不要急着重装系统或反复改协议，先确认是不是 IP 或端口被封锁，再决定换 IP、换入口，还是调整整体架构。
可以按下面的逻辑判断：国内多地测试超时，境外测试正常，服务端日志里也看不到对应的入站连接，基本可以判断是 IP 级封锁，流量在到达服务器前就被拦截了。如果只有某个端口不通，同一 IP 的其他端口正常，更可能是端口级封锁，或者这个端口上的协议特征被识别。如果只有个别用户异常，大多数用户正常，被墙的可能性较低，应先排查客户端和本地网络。
区分封锁、配置错误与网络质量问题
很多“被墙”其实是配置或线路问题。建议用“看到 A → 判断 B → 下一步 C”的方式逐条对照：
国内和境外都连不上：更像是服务器宕机、系统防火墙或云厂商安全组的问题。下一步用 systemctl status xray 查看进程状态，用 ss -lntp 确认端口是否在监听。境外通、国内所有端口都不通：典型的 IP 封锁，这时改配置意义不大，应准备新入口。单个端口不通、其他端口正常：先检查安全组和 iptables 规则，排除后再考虑端口级封锁。TCP 能连上，但客户端报 TLS handshake timeout、EOF 或证书错误：问题通常在 SNI、证书或协议参数上，不在 IP 本身。只有某个运营商或晚高峰出现高延迟、丢包：多半是线路拥塞，可以用 mtr 看丢包出现在哪一跳，再考虑换线路或加中转，不必当作被墙处理。
DNS、SNI、TLS、客户端与服务端的单节点排查步骤
单个节点异常时，按从外到内的顺序排查，可以少走弯路：
1）DNS：分别执行 dig +short 你的域名 @223.5.5.5 和 dig +short 你的域名 @1.1.1.1，对比两次结果。如果返回不一致或指向陌生 IP，可能是 DNS 污染，可以让客户端直接填 IP，或改用 DoH 解析后再测试。2）连通性：在国内机器上执行 nc -vz IP 443 或用 tcping 测试。超时就回到上一节，按 IP 或端口封锁处理。3）TLS 与 SNI：执行 openssl s_client -connect IP:443 -servername 域名，检查证书链和有效期。使用 Reality 时，还要核对 serverNames 与 dest 是否匹配。4）客户端：确认系统时间准确（VMess 对时间偏差敏感），并核对 UUID、传输方式、path、flow 是否和服务端一致。日志出现 context deadline exceeded，通常是网络不可达；出现 invalid user，通常是认证参数不匹配。5）服务端：执行 journalctl -u xray -f，同时让客户端发起连接。完全看不到入站记录，说明流量没有到达服务器；
有 rejected 等报错，则应回头修正配置。
换入口或调整配置后，如何验证真的恢复
节点被墙怎么确认已经恢复？不能只看管理后台显示“在线”，要从用户所在网络逐层验证。建议准备至少两个不同运营商的国内探测点，依次执行：nc -zv 入口IP 443 检查 TCP 能否建立；openssl s_client -connect 入口IP:443 -servername 你的SNI 检查 TLS 握手与证书；最后用客户端实际订阅做一次测速，并在服务端用 ss -tnp | grep 443 确认连接确实到达。
判断逻辑：看到 TCP 通、TLS 握手失败 → 多半是 SNI、证书或协议特征问题，下一步核对域名解析和证书链；看到多个运营商都 TCP 超时、海外探测正常 → 倾向入口 IP 被封，下一步换入口而不是改配置；看到入口通但落地日志无请求 → 中转转发规则或后端端口有误。恢复后建议持续观察 24 至 72 小时，记录首次失效时间，这比“当下能连”更能说明处理是否有效。
临时处理的边界：为什么换 IP 之后又很快失效
换 IP、换端口、换 SNI 属于低成本应急手段，适合单个节点偶发失效。但如果出现以下现象，就说明问题已超出单节点范围：新 IP 上线后几天内再次不可达；多个入口在相近时间段同时异常；换了协议和端口，失效节奏依旧相似。
常见根因通常不在某一行配置里，而在架构暴露面：订阅里直接写落地 IP，任何一个订阅泄露都会暴露源站；所有入口集中在同一网段或同一服务商，一旦被识别容易连带受影响；流量特征长期固定，入口负载集中。此时继续手动换 IP，只是在重复消耗资源，还会让用户频繁更新订阅，影响体验。
还需注意边界：没有任何配置能保证入口不被封锁，任何方案都只能降低暴露概率、缩短恢复时间。把目标从“永不失效”调整为“失效可快速定位、可平滑切换”，更符合实际运营情况。
入口、转发与后端解耦的长期思路及服务适用范围
长期来看，更稳妥的做法是把链路分为三层：入口层只负责接入，可批量替换；转发层负责把流量送到后端，隐藏真实落地地址；后端落地只接受来自转发层的连接，并在防火墙上限制来源。这样入口被封时，只需替换入口并更新订阅，落地与用户数据不受影响。配合 XBoard/V2Board 的节点管理，可以按线路分组下发，把故障影响控制在局部范围。
实施前建议先做好三件事：为每层建立独立的探测与告警；统一命名规则，从订阅名称就能看出节点对应哪个入口与哪条线路；预先演练切换流程，确认更换入口后客户端能正常拉取新配置。
如果你已经遇到多个入口或中转频繁失效、换 IP 后短期内反复出现，或者难以区分故障位于入口、中转还是落地，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/），它侧重多线路规划、降低源站暴露风险以及客户端与链路的故障排查。若只是单节点偶发问题，按前文自查通常已足够。
什么时候这已经不是单点配置问题
如果按上面的步骤排查后发现，问题不是单个节点配错，而是入口、中转、落地反复失效，或者每次换完 IP 很快又不可用，那就不是临时处理能解决的了，需要从整体链路重新规划。这类情况可以参考 Manguo Labs 的机场高可用入口解决方案，先把故障分层定位清楚，再评估入口、转发和后端怎么拆开、怎么切换。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
本文面向的是机场运营者遇到的节点或入口被墙问题，和 Manguo Labs 机场高可用入口解决方案覆盖的范围一致：入口、中转、落地链路的高可用规划和故障排查，帮助区分是哪一层出了故障、设计切换方案，适合多个入口或中转频繁失效、换 IP 后很快又被封的情况。单个节点的配置错误，按本文的自助排查处理就可以。
适合这些情况
- 多个入口或中转频繁失效，靠单点换 IP 已经跟不上
- 换 IP 后没多久又反复被封
- 需要区分入口、中转和落地哪一层坏了，并设计切换方案
常见问题
怎么快速判断节点是被墙，还是服务端挂了？
分别在境外 VPS 和国内多个地区对节点 IP 做 ping 和 tcping（或者 nc -zv IP 端口）。境外通、国内全不通，就像是 IP 被封；境内外都不通，先看服务端进程（systemctl status 查看状态、ss -lntp 看端口有没有在监听）、防火墙和机房状态；国内 TCP 能通但客户端报握手失败，多半是 SNI、证书或协议参数配错了，不是被墙。
只封了端口和整个 IP 被封，处理起来有什么不一样？
如果换个端口国内就能连上，但原端口在境外正常，那更像是端口级阻断，可以先换端口，同时留意之后会不会再次被封。如果所有端口在国内都不通，ICMP 也不通，那基本是 IP 级封锁，换端口没用，只能换 IP，或者把流量切到备用入口。
换了 IP 没几天又被墙，问题出在哪？
常见原因有：源站 IP 直接写在订阅里，已经暴露；新 IP 和旧 IP 在同一个段或同一家机房；流量特征和协议配置都没变；订阅被分享扩散，新地址很快又被收集走。这种时候反复换 IP 解决不了根本问题，要看入口是不是跟后端绑死了，订阅下发出去的地址是不是可以随时替换。
客户端报 TLS handshake 错误，一定是被墙了吗？
不一定。先检查几项：SNI 和证书域名对不对得上，证书有没有过期，Reality/TLS 的 serverName 和公钥参数跟服务端是否一致，客户端内核版本是否支持当前协议，系统时间有没有偏差太多。只有这些都没问题、境外测试正常而国内持续失败，才需要考虑是不是针对 SNI 或 TLS 特征的阻断。
入口、中转、落地拆开部署，一定就不会被墙吗？
不会。拆开部署的意义是降低源站暴露的风险，让某一层出问题时能单独替换或切换，避免整条链路一起中断，但没法保证永远不被封。它要配合监控、备用线路和切换流程一起用，才有实际效果。
总结与下一步
判断被墙时，先对比境内和境外的探测结果，把“封锁”“配置错误”“网络或服务端故障”分开；然后按 DNS、SNI、TLS、客户端、服务端单节点的顺序排查，再按入口、中转、落地逐层确认是哪一层坏了。换 IP、换端口、改协议参数都只是临时办法。如果换 IP 后很快又失效，或者多个入口同时出问题，就要从源站有没有暴露、入口和后端是否绑死、订阅能不能快速替换这几个方面去改架构，把入口、转发、后端拆开，并提前准备多线路切换方案。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →