被墙了换哪个好：先定位，再选方案
很多机场运营者搜“被墙哪个好”，真正想问的是：节点被墙后，换 IP、换协议、加中转还是走 CDN，哪个更好？直接回答是，没有一种方案在所有场景下都最好，要先确认是不是真的被墙，再按故障所在的层级选择。只是单个入口 IP 被封，换 IP 是成本最低的临时办法。同一种协议特征在多个 IP 上相继失效，应优先调整协议与传输方式，例如改用 VLESS + Reality，或改为 TLS + WebSocket/gRPC 经 CDN 转发。如果换 IP 后几天内又失效，问题出在入口的暴露方式，继续换 IP 意义不大，需要考虑入口、中转、落地分层解耦。
判断“哪个好”不看某个协议名气大不大，而看三点：入口被识别后能否快速切换，源站是否暴露，切换成本是否可控。下面先讲怎么区分故障类型，再给出可以照着执行的排查步骤。
区分封锁、配置错误与线路波动
大量“被墙”报告其实是配置问题或线路波动，误判之后换 IP 只会浪费资源。可以按“看到 A → 判断 B → 下一步 C”的方式快速分流。
看到国内多地 TCP 连接超时，而海外探测机器连同一 IP 和端口正常，说明大概率是 IP 或端口被封锁，下一步换入口 IP 或改由中转接入。看到 TCP 能连上，但 TLS 握手阶段被 reset，换一个 SNI 后又恢复，说明是 SNI 或协议特征被针对，下一步调整伪装域名或传输方式。看到国内和海外都连不上，问题通常在服务端本身，例如进程未启动、证书过期或防火墙规则错误，这时应查服务端，不要急着换 IP。看到客户端日志出现 x509 证书错误、invalid user 或 UUID 不匹配，属于配置问题。白天正常、晚高峰丢包严重，mtr 显示某一跳持续丢包，属于线路拥塞，需要换线路或优化中转，与封锁无关。
DNS / SNI / TLS / 客户端 / 服务端逐项排查步骤
建议从一台国内机器和一台海外机器同时执行，对比结果比单点测试可靠。
1）DNS：执行 dig 你的域名 @223.5.5.5，再执行 dig 你的域名 @8.8.8.8 对比。返回的 IP 与真实 IP 不符或解析为空，说明存在 DNS 污染，先用 IP 直连测试，再考虑更换域名。 2）TCP：执行 nc -vz 入口IP 443。国内超时而海外成功，基本可以判定为 IP 或端口封锁。 3）TLS/SNI：执行 openssl s_client -connect 入口IP:443 -servername 伪装域名。握手中途断开，而换一个 SNI 后正常，说明 SNI 被针对。 4）客户端：检查系统时间是否同步，再核对 UUID、传输路径、Reality 公钥等字段是否与服务端一致。日志中的报错比“连不上”这个现象更有价值。 5）服务端：用 ss -tlnp 确认端口在监听，用 journalctl -u xray 查看报错，用 openssl x509 -enddate 检查证书有效期。
五步都正常却仍然不可用时，再按入口、中转、落地逐层定位。
切换后的覆盖验证：多运营商、多时段确认结果
换了协议或入口后，只用一台设备测一次还不能下结论。“被墙哪个好”最终要看覆盖面。至少用电信、联通、移动三类网络，分别在白天和晚高峰各测一轮，并把结果和时间点记录下来。 建议按层验证。第一步，用 mtr -T -P 443 入口IP 查看 TCP 路径，确认是否在某一跳之后全部丢失。第二步，用 openssl s_client -connect 入口IP:443 -servername 你的域名 观察 TLS 握手。 结果可以这样判断： - 三网都出现 SYN 超时：多半是入口 IP 被封锁，下一步换入口，而不是改配置。 - TCP 可达，但握手阶段出现 connection reset 或 unexpected eof：偏向 SNI 或协议特征被识别，下一步检查伪装域名和 TLS 参数。 - 只有单一运营商失败：优先怀疑线路质量或中转路由。 客户端侧要同时核对 Clash 或 sing-box 日志里的 dial tcp i/o timeout 和 tls handshake 错误。每次结论都留档，后续才能判断是不是反复失效。
失败边界：哪些情况换协议也解决不了
自助调整有明确边界。换协议、换端口、调整 SNI，解决的是单节点特征或配置问题。如果同一机房新换的 IP 几天内又陆续不可用，问题就不在某个协议，而在暴露面本身。常见原因有：入口地址被大量订阅分发，源站 IP 曾直接对外，或者所有线路共用同一个落地。 以下几种情况，换哪个协议都难以改善： - 落地服务器所在 IP 段整体信誉较差，任何入口转发过去都会受影响。 - 订阅链接或面板域名本身受到干扰，客户端连配置都拉不下来。 - 中转只有一条，任何一处出问题就全线中断。 可以通过对比来定位： - 不同入口同时失败，而落地直连正常：问题在入口层。 - 入口可达，但到落地超时：排查中转。 - 所有路径都卡在同一个落地：更换或增加落地。 到了这一步，继续频繁换 IP 只会推高成本，也无法预期能稳定多久，应该转向架构层面的调整。
长期架构：入口、转发、后端解耦与方案适用边界
长期思路是把入口、转发和后端解耦： - 入口层准备多组可替换的地址，只负责接入。 - 中转层按运营商或地区分组，负责选路。 - 落地和源站不直接对外暴露，面板与订阅服务也和节点分开部署。 这样某个入口失效时，只需在 XBoard/V2Board 中更新对应节点或下发新入口，用户刷新订阅就能切换，后端不用跟着迁移。再配合定时的多网探测，可以在用户大面积反馈之前发现异常。 如果你已经遇到这些情况：多个入口或中转频繁失效，换 IP 后短期内又出问题，或者团队分不清故障在入口、中转还是落地，可以参考 Manguo Labs 的机场高可用入口解决方案。它可以协助做链路分层排查、多线路与批量部署规划，以及降低源站暴露风险的切换设计，详见 https://manguolabs.com/node-firewall/。 如果只是单个节点配置错误，按前文步骤自查通常就够了，不必引入额外方案。另外，任何架构都只能降低风险，不能消除被封锁的可能。
什么时候这已经不是单点配置问题
如果你按上面的步骤排查后发现，问题已经不在某一个节点的配置上，而是多个入口反复失效、换 IP 也只能撑一小段时间，那么继续单点修补的收益会越来越低。这时可以参考入口、中转、落地分层的高可用规划思路，或者找已有方案评估一下现有链路。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
本文面向的是机场运营者常问的“被墙哪个好”。单节点问题可以靠文中的排查步骤自己处理。跨越单个节点的问题，比如多个入口或中转频繁失效、换 IP 后短期内又出现故障、需要区分入口、中转与落地故障并设计切换方案，就对应到 Manguo Labs 的机场高可用入口解决方案。
适合这些情况
- 多个入口或中转频繁失效的机场运营者
- 换 IP 后短期内反复出现封锁的场景
- 需要区分入口、中转与落地故障并设计切换方案的团队
常见问题
怎么快速判断节点是真被墙，还是配置出了错？
分别从国内和海外测同一个 IP 和端口。海外能通、国内 ping 和 tcping 都超时，基本是 IP 被封。国内 TCP 能通，但客户端日志里出现 TLS handshake timeout 或 EOF，更像协议特征被识别，或者 SNI 配置有问题。两边都不通就先查服务端：用 systemctl status 看进程，用 ss -lntp 看端口监听，再看防火墙规则。
被墙后换 IP 和换协议，哪个好？
整个 IP 都不通（ICMP 和 TCP 全部失败），换 IP 是最直接的办法。IP 可达、只有某个端口或协议握手失败，先换协议或调整 TLS 参数，成本更低。换完很快又失效，说明暴露方式没变，只换 IP 或协议都不能解决根本问题。
加中转一定比直连好吗？
不一定。中转能把落地 IP 藏在后面，让入口可以单独替换。但它也多了一跳延迟和一个故障点，中转线路本身的质量和稳定性也要考虑。如果入口地址仍然对外大量暴露、没有切换机制，中转被封以后，影响和直连被封差不多。
换完 IP 很快又被封，常见原因有哪些？
常见原因包括：新 IP 在订阅里和旧节点用同样的方式公开下发；协议特征和端口模式没变；落地 IP 直接暴露给用户；所有入口集中在同一个网段或同一家服务商。这些问题要从入口分发和架构设计上处理。
什么情况下该考虑高可用入口方案？
多个入口或中转频繁失效、换 IP 后短期内又出问题，或者每次故障都要人工逐个节点去查，这时单点修补的成本已经很高。更适合规划入口、转发和后端分层解耦，并配好切换策略。
总结与下一步
节点被墙后，第一步是确认是不是真被墙，不急着选方案：先用国内外对比测试、DNS/SNI/TLS 检查和客户端日志，排除配置和网络问题，再按入口、中转、落地逐层定位故障。单 IP 被封就换 IP，协议被识别就换协议。如果反复失效，根因通常在暴露面和架构上，长期办法是把入口、转发和后端解耦，并设计切换机制。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →