节点被墙如何解决：先判断，再分层处理
节点被墙后，不要一上来就换 IP。先确认是不是真的被封，再看问题出在哪一层。单个节点被封时，可以临时更换入口 IP 或端口，也可以调整协议和伪装方式恢复使用。如果多个入口在换 IP 后短期内又失效，单纯更换已经不够，需要把入口、中转、落地拆开，设计可切换的多入口架构，减少单点失效对全体用户的影响。
用户反馈通常是“连不上”“延迟突然变高”“只有某个运营商能用”。可以按下面三种情况初步判断：国内各地全部超时，海外探测正常，大概率是入口 IP 被封锁；只在某个省份或运营商、晚高峰出问题，更像线路拥塞或限速；国内外都连不上，应先排查服务端和配置，而不是急着换 IP。
区分封锁、配置与网络问题
判断的核心是对比测试：同一个目标，分别从国内和海外测试，并分别测试 ICMP、TCP 和 TLS 三层。
IP 级封锁的表现是：国内 ping 和所有端口的 TCP 都不通，海外一切正常，同机房的其他 IP 不受影响。端口级封锁的表现是：国内连 22 端口可以握手，443 或代理端口超时，换一个端口后短暂恢复。协议或 SNI 识别的表现是：TCP 三次握手成功，进入 TLS 握手后连接被重置，客户端日志常见 connection reset by peer 或 TLS handshake timeout。
配置问题的特点是海外同样失败，服务端日志里有明确报错，例如证书域名不匹配、UUID 错误、传输方式不一致。网络质量问题则通常不会完全中断，而是丢包率随时段波动，用 mtr 能看到某一跳之后持续丢包。看到“海外正常、国内全断”，判断为封锁，下一步换入口；看到“两边都失败”，判断为配置或服务问题，下一步查日志。
DNS、SNI、TLS 与客户端、服务端单节点排查步骤
对单个故障节点，建议按以下顺序逐层排查，确认一层正常后再查下一层。
1）DNS：执行 dig +short node.example.com，再执行 dig +short node.example.com @1.1.1.1，对比两次结果。如果解析到陌生 IP 或旧 IP，说明存在解析污染或缓存未更新。 2）TCP：在国内和海外机器上分别执行 nc -vz 入口IP 443。国内超时、海外成功，按封锁处理。 3）TLS 与 SNI：执行 openssl s_client -connect 入口IP:443 -servername node.example.com。能返回证书，说明链路可达；握手中途被重置，怀疑 SNI 或特征被识别；如果提示证书过期或域名不符，属于配置问题。 4）服务端：执行 ss -tlnp | grep 443，确认端口在监听；再用 journalctl -u xray -n 50 查看近期报错。 5）客户端：检查系统时间是否同步（VMess 对时间误差敏感），确认订阅已更新、核心版本支持当前协议。
处理后如何验证恢复：分层复测与观察窗口
处理完成后，不能只看客户端能否打开一个网页，应按入口、中转、落地三层分别复测。第一步，从国内多个运营商的探测点执行 tcping 入口IP 443，确认 TCP 握手稳定。第二步，用 openssl s_client -connect 入口IP:443 -servername 你的SNI 检查证书链与握手是否完成。如果握手正常、但随后连接被重置，多半是特征或 SNI 层面的干扰，应先检查伪装域名与协议配置，而不是继续换 IP。入口正常后，在中转机上用 curl -v --resolve 测试到落地的链路，再在落地机上执行 curl -I https://www.google.com，确认出口可用。
复测通过后，至少保留 24 至 72 小时观察窗口。期间记录各入口在晚高峰的丢包与延迟，并对照服务端日志，看连接数是否回升。如果只有某一运营商的用户报错，而其他探测点正常，应按区域线路问题处理。如果全网同时恢复、又同时失效，就要怀疑入口 IP 已被持续关注。
临时方案的失败边界：什么时候换 IP 已经不够
换 IP、换端口、更换 SNI 都属于低成本的临时手段，能处理的是单个入口被封、配置被识别这类局部问题，但有明确边界。典型判断是：新 IP 上线后，数小时到数天内再次 TCP 不通，说明问题不在单个地址，而在暴露方式。常见原因包括入口 IP 被直接写进订阅、面板与节点同机部署、大量用户集中连接同一地址。这时应排查订阅下发和源站暴露面，而不是继续购买新 IP。
另一类边界是多层同时异常：入口能握手，中转日志也有连接，但落地出口频繁超时，此时更换入口完全无效。还有一种情况是敏感时期的大范围干扰，任何单节点调整都只能缓解，不能保证恢复。如果同一问题在短期内反复出现，或已经涉及多个入口和中转，就应停止逐个救火，转向架构层面的调整。
长期架构与高可用方案的适用边界
长期思路是把入口、转发和后端解耦。入口层使用多个可替换的 IP 或域名，DNS 设置较低 TTL，并配合健康检查自动摘除失效入口。中转层负责线路优化与故障切换，不直接暴露落地。落地与面板（如 XBoard/V2Board）分离部署，订阅中只下发入口信息，以降低源站暴露风险。这样某一入口失效时，影响范围被限制在单层，可以通过批量部署新入口快速替换，而不必改动后端。
如果是个人自用、只有一两个节点，前面的自助排查通常已经足够。如果你是机场运营者，遇到以下情况，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/）：多个入口或中转频繁失效、换 IP 后短期内反复出现，或者需要明确区分入口、中转与落地故障并设计切换方案。该方案涵盖多线路规划、批量部署和客户端检查。需要说明的是，任何架构都只能降低被墙的影响与恢复成本，无法承诺长期不受干扰。
什么时候这已经不是单点配置问题
如果按上述步骤排查后，问题已经超出单个节点配置的范围，例如多个入口或中转反复失效、换 IP 后很快又被封，那么再换一次 IP 通常解决不了问题，需要对入口、中转、落地链路做整体规划。这类情况可以参考 Manguo Labs 的机场高可用入口解决方案。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
本文面向遇到节点被墙的机场运营者。单节点配置错误或偶发封锁，用文中的自助步骤通常就能处理。Manguo Labs 的机场高可用入口解决方案面向更复杂的场景：多个入口或中转频繁失效、换 IP 后短期内反复出现，以及需要区分入口、中转与落地故障并设计切换方案的情况。
适合这些情况
- 多个入口或中转频繁失效的机场运营者
- 换 IP 后短期内又反复被封的场景
- 需要区分入口、中转与落地故障，并设计切换方案的团队
常见问题
怎么快速判断节点是被墙了还是配置错了？
在境内和境外各执行一次 tcping 或 nc -vz 测试入口端口。境外通、境内超时，大概率是封锁；两边都不通，先查服务端进程、防火墙和端口监听（ss -lntp）。端口能通但客户端报 TLS 或 handshake 错误，优先核对 SNI、证书和协议参数。
只是端口被封，换个端口就够了吗？
如果 ping 通、只有某个端口不通，换端口通常能临时恢复。但如果流量特征或 TLS 指纹已经被识别，新端口也可能很快失效。整个 IP 都不通时换端口没有用，需要换 IP 或切换入口。
为什么换了 IP 没几天又被封？
常见原因有：源站 IP 直接写在订阅里，入口与落地是同一台机器，协议或 SNI 特征明显，或者新 IP 所在网段本来就已被重点关注。只换 IP、不调整架构，同样的情况很容易反复出现。
中转和落地哪一层出了问题怎么区分？
从中转机直接用 curl 或 tcping 测落地端口：能通，问题在入口到中转这一段；不通，再从境外其他机器测落地，排除落地服务本身的故障。逐层单独测试，就能把故障锁定在具体某一段。
有没有办法彻底避免入口失效？
没有方案能承诺入口不会被封。更现实的目标是：降低源站暴露风险，让入口可以快速替换，并准备多条线路用于切换，从而缩短故障对用户的影响时间。
总结与下一步
解决被墙问题，第一步是确认是否真的被封：用境内外对照测试区分封锁、配置和网络问题。然后按 DNS、SNI、TLS、客户端、服务端逐项排查，再分入口、中转、落地三层定位故障。换端口、换 IP 只能临时恢复；如果反复失效，就应把入口、转发和后端解耦，隐藏源站，准备多条线路并设计切换流程。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →