节点被墙怎么办：先确认是不是真的被墙
节点连不上时，不要马上换 IP，先判断是不是真的被墙。“被墙”一般指境内到服务器 IP 或端口的通信被干扰：境内 ping 不通或 TCP 握手超时，同一台服务器从境外访问却一切正常。常见的另一种情况是端口能通，但带特定 SNI 或特征的 TLS 连接被重置。确认被墙后，临时办法是换入口 IP、换端口或切到备用线路；长期要把入口、中转、落地拆开，避免一个 IP 失效导致整条线路不可用。
很多“被墙”其实是证书过期、配置改错、服务进程挂掉或机房线路抖动。判断方法是分别在境内和境外做同样的测试，对比结果：境外正常、境内异常，才偏向封锁；两边都异常，先查服务端本身。先分清楚再处理，才不会把可以修的配置问题错当成 IP 失效，白白换掉一个还能用的地址。
区分封锁、配置与网络问题
可以按下面的对应关系快速分类。看到境内 ping 和所有端口都超时，境外全部正常，基本是 IP 级封锁，下一步准备新的入口 IP 或切换中转。看到 ping 正常、TCP 端口能连上，但客户端日志报 connection reset by peer 或 TLS handshake 失败，而境外测试正常，多半是端口或协议特征受到干扰，可以先换端口、调整 SNI 或传输方式试一试。
看到境内外都连不上，就要检查服务端：进程有没有在运行、端口有没有监听、防火墙和安全组有没有放行。客户端报 x509 证书错误或 certificate has expired，是证书问题，和封锁无关。只有晚高峰变慢、丢包，白天恢复，通常是线路拥塞，属于网络质量问题，换 IP 解决不了，应该考虑优化线路或加中转。另外，同一批用户里只有某个运营商或某个地区报障，也更像是局部路由问题，而不是全面封锁。
DNS / SNI / TLS / 客户端 / 服务端单节点排查
对单个节点，建议按下面的顺序逐层检查： 1. DNS：在境内执行 dig example.com，确认解析结果就是当前服务器 IP，排除解析被污染或记录没有更新。 2. 连通性：用 tcping 或 nc -zv IP 443 测端口，同时在境外 VPS 上执行同样的命令做对照。 3. TLS 与 SNI：执行 openssl s_client -connect IP:443 -servername 你的域名，查看是否能完成握手、证书链和有效期是否正常；再换一个 SNI 对比结果。 4. 服务端：用 ss -lntp 确认端口在监听，用 systemctl status 和 journalctl -u xray 查看进程状态与报错。 5. 客户端：核对地址、端口、UUID、传输方式和 SNI 是否与服务端一致，并确认客户端和核心版本不过旧。
如果前 4 步都正常、只有境内握手失败，就可以基本判断为封锁。任何一步出现明确报错，都先修复那一层，不要急着换 IP。
处理后的覆盖验证：分地区、分运营商、分时段确认恢复
换 IP、改端口或调整配置后，不要只凭自己一台设备能连上就认定已经恢复。至少选择电信、联通、移动三个运营商，以及两个以上省份作为探测点，分别检查三层：先用 nc -vz -w 3 入口IP 443 看 TCP 能否建立；再用 curl -v --resolve sub.example.com:443:入口IP https://sub.example.com 观察 TLS 握手是否完成；最后用客户端实际拉取订阅、连接节点，检查延迟和丢包。
判断逻辑可以这样走：TCP 连接超时，而且只在某个运营商出现，大概率是线路或运营商层面的问题，下一步看路由和 mtr 结果；TCP 能建立，但 TLS 阶段被重置或长时间卡住，更可能和 SNI、证书或协议特征有关，下一步检查伪装域名和传输配置；三层都通，但用户仍反馈断流，就回到服务端，用 ss -tn state established 查看连接数，同时看 Xray 或 sing-box 日志里的 EOF、timeout 是否集中出现。验证时间建议持续 24 到 72 小时，覆盖晚高峰。很多入口刚换上时正常，几天后才会复现问题。
临时办法的失效边界：什么时候应停止单纯换 IP
更换入口 IP、换端口、临时加一层 CDN 或中转，都能在短期内恢复访问，处理单个节点偶发故障也有效。但它们只绕开了当前被封锁的具体地址，没有消除导致封锁的原因。出现以下现象时，说明已经到了临时办法的边界：新 IP 上线几天内再次不可达；多个入口在同一时段一起失效；更换云厂商后问题仍然规律性出现；只要换 IP，就会先后同步到所有用户的订阅里。
遇到这些情况，应该去找多个入口的共同点，而不是继续换 IP。常见的共同点包括：入口集中在同一个 ASN 或同一个网段；所有节点使用相同的协议参数和伪装域名；订阅里直接下发了落地机的真实 IP；面板域名、订阅域名和节点域名解析到同一台机器。只要其中一项被识别，换多少 IP 都可能很快再次暴露。另外，频繁换 IP 还会带来额外成本、迁移时间，以及订阅更新期间用户集中断连。这时候应该先停下来梳理链路结构。
长期架构思路与机场高可用入口解决方案的适用边界
长期方案的核心是解耦入口、转发和后端。入口层分布在不同的 ASN 和地区，只负责接入，可以随时替换；转发层把入口和落地隔开，落地机的真实地址不出现在订阅中；后端的面板、订阅和节点使用不同的域名和主机，某一层暴露也不会连带其他层。在 XBoard 或 V2Board 里，可以按线路给节点分组，配合健康检查，在某个入口不可用时及时调整下发的节点列表。这样用户看到的是切换，而不是整体中断。这种做法能降低单点失效的影响范围，但无法让节点永远不被封锁。
如果只是单个节点配置错误、证书过期或端口没放行，按前文步骤自行排查就能解决，不需要引入外部方案。如果已经出现多个入口或中转频繁失效、换 IP 后短期内反复出现，或者需要系统地区分入口、中转和落地故障并设计切换方案，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/）。它提供链路规划和故障排查，也支持多线路批量部署和客户端检查。接入前建议先整理好现有拓扑和失效记录，再评估是否适用。
什么时候这已经不是单点配置问题
如果按上面的步骤排查后，确认只是单节点配置或偶发封锁，自己处理就够了。如果入口反复失效、换 IP 也撑不了多久，或者多条线路的故障无法清楚归到某一层，那就是架构问题了，这时可以参考成熟的高可用入口方案来规划切换与解耦。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
当问题已超出单个节点配置，例如多个入口或中转频繁失效、换 IP 后短期又被封、无法区分入口/中转/落地故障时，Manguo Labs 的机场高可用入口解决方案提供入口、中转与落地链路的高可用规划和故障排查，可配合 XBoard/V2Board 场景设计切换方案，降低源站暴露风险。
适合这些情况
- 多个入口或中转频繁失效的机场运营者
- 换 IP 后短期内又被封，需要找根因的场景
- 需要区分入口、中转与落地故障并设计切换方案
- 使用 XBoard/V2Board，需要多线路批量部署与故障排查
常见问题
怎么快速判断是被墙，还是服务端挂了？
同时从国内和海外测试同一 IP 和端口：用 ping、tcping 或 nc -vz 看 TCP，用 curl -v 或 openssl s_client 看 TLS 握手。海外正常、国内全不通 → 大概率是 IP 被封；海外也不通 → 查进程（systemctl status）、防火墙和证书；国内 TCP 通但握手被重置 → 更可能是 SNI 或协议特征被干扰。
只有部分端口不通，算被墙吗？
有可能是端口级封锁，也可能是安全组或防火墙配置问题。先看服务器上 ss -lntp 有没有在该端口监听，再核对云厂商安全组规则。配置都没问题，但国内只有这个端口不通，可以换端口临时验证；如果换端口很快又失效，就说明特征或 IP 已经被关注，不能只靠换端口。
换了新 IP 没几天又被封，是什么原因？
常见原因包括：源站 IP 仍然直接暴露给大量用户、订阅泄露后被扫描、协议或 TLS 指纹特征明显、同一网段历史记录不好。只换 IP 不改架构，新 IP 会重复同样的暴露路径。更稳妥的做法是：入口层可替换，中转承担转发，落地和面板不直接暴露。
入口、中转、落地哪一层出问题，怎么分辨？
逐跳测试：客户端到入口能不能建立 TCP/TLS；在入口机上测到中转的连通性和延迟；在中转上 curl 目标网站，看落地出口是否正常。哪一跳开始失败就定位在哪一层。只有部分地区或运营商失败时，入口被封的可能性更大；所有地区都失败时，优先查中转或落地。
总结与下一步
被墙怎么办的核心是先判断，再处理：通过国内外对比测试区分 IP 封锁、SNI/TLS 干扰、配置错误和服务端故障；再按入口、中转、落地逐跳定位失败点。换 IP、换端口、调整伪装域名可以临时恢复，但不能解决反复失效的问题。长期应把入口、转发和后端解耦，让入口可以快速替换、多线路互为备份、源站尽量不暴露，同时配合客户端侧检查，缩短故障恢复时间。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →