节点被墙的常见现象与直接判断
节点“被墙”最典型的表现是：客户端显示超时或握手失败，但服务器本身运行正常；从海外机器或服务器本机测试端口一切正常，从国内多个运营商测试却同时不通；有时 ping 正常而 TCP 端口不通，也有时整个 IP 都 ping 不通。直接判断很简单：只有国内不通、海外正常，而且在电信、联通、移动三网都复现，才比较接近封锁；如果只有个别用户或单一运营商异常，应优先怀疑配置、线路质量或客户端问题。
所以这篇被墙教程的第一条原则是：先证明问题出在“墙”，再去换 IP、换端口或换协议。很多运营者一看到大面积报错就立刻换 IP，结果发现根因是证书过期、DNS 解析错误或服务端进程崩溃，不仅白白浪费资源，还会让真正的故障更难复现。如果问题已经证实是封锁，也要分清是整个 IP 被封、单个端口被阻断，还是特定 SNI 或协议特征被干扰，因为这三种情况的处理方式完全不同。
区分封锁、配置错误与普通网络问题
三类问题的日志表现差异很明显。看到国内 ping 与所有端口都不通，海外探测正常 → 判断为 IP 级封锁 → 下一步考虑更换入口 IP，而不是改配置。看到 ping 正常但只有代理端口在国内不通，其他端口能通 → 判断为端口阻断或协议特征被识别 → 下一步检查端口与传输协议。看到 TCP 能连上，但 TLS 握手被重置或长时间无响应，并且换一个 SNI 后恢复 → 多半是针对 SNI 的干扰。
配置错误则通常具备“海外也不通”这个特征：服务端日志出现 failed to read request、invalid user 或 UUID 不匹配，或者证书已过期、域名解析到了旧 IP。普通网络问题的特点是时好时坏、晚高峰丢包高、只影响某个运营商，用 mtr 能看到某一跳之后丢包明显升高，而端口本身并没有被阻断。把这三类问题分开记录，后续是否需要调整架构才有依据，否则每次故障都只会变成一次盲目换 IP。
DNS、SNI、TLS 与客户端服务端的单节点排查步骤
建议按从底层到上层的顺序，逐项排除：
1. 解析检查：执行 dig 节点域名 @223.5.5.5 和 dig 节点域名 @8.8.8.8，对比返回结果，确认国内外都解析到当前 IP，没有旧记录或被污染的结果。 2. 连通性检查：分别从国内和海外执行 nc -zv IP 端口，或使用 tcping，区分 IP 级与端口级的不通。 3. TLS 检查：执行 openssl s_client -connect IP:443 -servername 你的SNI，确认证书链完整、证书未过期，并且 SNI 与证书匹配。 4. 服务端检查：执行 ss -tlnp 确认进程确实在监听，用 journalctl -u xray -n 100 查看是否有认证或协议报错。 5. 客户端检查：核对订阅中的地址、端口、UUID、传输方式与服务端是否一致，同时排查本地系统时间偏差和其他代理软件冲突。
如果五步都正常，只有国内三网都不通，就基本可以确认是封锁。如果某一步失败，就先修复这一步，再回到上一步复测，避免多个变量同时改动。
修复后的覆盖验证：怎样确认节点真的恢复
按被墙教程做完换 IP、改 SNI 或调整端口后，不能只在自己电脑上点一次“测速成功”就收工。建议至少用三类网络交叉验证：电信或联通家宽、移动 4G/5G、一台境外 VPS。在本地执行 tcping 203.0.113.10 443 看端口连通性，再用 openssl s_client -connect 203.0.113.10:443 -servername cdn.example.com 确认 TLS 握手与证书链正常，最后用 curl -v --resolve sub.example.com:443:203.0.113.10 https://sub.example.com/ 检查订阅域名能否走到预期入口。
判断逻辑：境外通、国内全部超时，说明仍是入口被阻断，下一步换入口而不是改配置。只有移动网络失败，多半是运营商线路差异，需要考虑多线路入口。握手成功但客户端日志持续出现 connection reset 或 context deadline exceeded，应回头核对 UUID、传输协议与 path。验证周期建议覆盖 24 到 72 小时，包括晚高峰，否则“刚修好”很可能只是暂时没被识别。
失败边界：哪些情况单靠教程处理不了
被墙教程能解决的，主要是单节点配置错误、证书过期、端口被单独封锁这类问题。以下几种信号出现时，说明问题已经超出单点修复范围：一是新 IP 上线后几天内再次失效，反复多轮，说明入口特征或暴露路径本身没变；二是多个入口在同一时段集中失效，而落地服务器在境外检测一切正常，问题在入口层而非后端；三是中转机正常、落地机却被直连探测到，往往是订阅里直接写了落地 IP，或面板、回源域名解析泄露了源站。
这些情况下继续换 IP，只是在重复同一个暴露过程，成本会越来越高，用户体感也越来越差。还要注意，任何调整都只能降低被识别和被阻断的概率，无法对抗网络策略本身的变化，不存在一劳永逸的配置。判断到这一步，重点应从“修好这一台”转向“出问题时谁能顶上、多快能切换”。
长期架构思路与服务适用边界
长期方案的核心是入口、转发、后端解耦：用户只接触可替换的入口层，入口经中转连接落地，落地 IP 不出现在订阅和公开解析中，从而降低源站暴露风险。入口准备多条线路并按运营商分组，配合健康检查，某个入口失效时在订阅侧切换，而不是逐台改落地配置。如果使用 XBoard 或 V2Board，节点地址应指向入口层，后端变更不影响用户订阅；节点数量多时，用脚本批量部署与统一校验，减少手工改错。
如果你遇到的是多个入口或中转频繁失效、换 IP 后短期内反复出现，或需要区分入口、中转与落地故障并设计切换方案，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/），内容涵盖链路的高可用规划、多线路部署和客户端侧故障排查。反过来，如果只是单台节点证书过期或端口写错，按前文步骤自行处理通常就够了，不必为此引入更复杂的架构。
什么时候这已经不是单点配置问题
如果按上面的步骤排查后，问题仍然跨越多个节点，或者入口、中转、落地反复失效，那么继续逐个换 IP 的成本会越来越高。这时更适合从架构层面规划入口分层和切换方案。可以参考 Manguo Labs 的机场高可用入口解决方案，先评估现有链路是否适合。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
Manguo Labs 的机场高可用入口解决方案面向机场运营者，提供入口、中转与落地链路的高可用规划和故障排查，适合多个入口或中转频繁失效、换 IP 后短期内又出问题、需要区分各层故障并设计切换方案的场景。单个节点的配置错误可以按本文自行处理，不需要这个方案。
适合这些情况
- 多个入口或中转频繁失效的机场运营者
- 换 IP 后短期内问题反复出现的场景
- 需要区分入口、中转与落地故障并设计切换方案的团队
常见问题
怎么快速判断节点是被墙，还是配置写错了？
在境内用 ping、tcping 或 nc -vz 测入口端口，同时从境外 VPS 测同一地址。如果境内不通、境外正常，大概率是 IP 或端口被封锁；如果境内外都不通，先查服务端进程和防火墙；如果 TCP 能通，但客户端日志报 TLS handshake timeout 或证书错误，应该检查 SNI、证书和协议配置。
只换端口就恢复了，说明什么？
这通常说明封锁只针对端口，或者是基于特征的阻断，IP 本身暂时还能用。可以先把服务迁到新端口应急，但如果流量特征没有变，新端口也可能很快再次失效，应该同时复查协议、伪装域名和 TLS 配置。
入口、中转、落地都有，怎么定位是哪一层出了问题？
逐层测试：先从境内直连入口端口；再在入口机上用 curl 或 nc 测中转；最后在中转机上测落地。哪一跳不通，就在哪一层处理。如果入口正常、落地也能单独访问，但整条链路仍然失败，重点检查转发规则和端口映射。
换 IP 之后很快又被墙，是什么原因？
常见原因有：源站或入口 IP 通过订阅、面板域名、DNS 历史记录等途径暴露；协议特征比较明显；所有用户集中在少数几个入口上。只换 IP 解决不了暴露途径，需要把入口、转发和后端解耦，并准备可切换的多条线路。
自己排查到什么程度，就该考虑整体方案了？
如果问题只出在单个节点，并且通过修改配置能解决，自己处理就够了。如果多个入口或中转反复失效，换 IP 后短期内又出问题，或者分不清是哪一层故障，就需要做分层架构和切换方案的规划。
总结与下一步
所谓“被墙”，首先要通过境内外对比测试来确认，同时排除 DNS、SNI、TLS、客户端和服务端单节点的配置问题，再按入口、中转、落地逐层定位。换端口、换 IP 只能临时恢复。如果反复失效，根源通常是入口暴露加上架构耦合，长期做法是把入口、转发和后端解耦，配合多线路和切换预案，以降低单点风险。这些措施都不能保证不再被封锁。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →