被墙如何排查：从现象判断到入口、中转、落地分层定位

被墙如何排查：先看现象，再下判断

节点"被墙"通常不会直接报错。常见表现是客户端显示超时，延迟测试全红，但服务器面板、SSH 和服务进程看起来都正常。排查时第一步不是急着换 IP，而是先回答一个问题：故障只出现在国内网络，还是境内外都连不上。如果境外机器能正常访问节点端口，国内多个运营商同时超时，那么封锁的概率较高。如果境外也连不上，问题多半在服务端配置、证书、防火墙或进程本身。

还有一种常被误判的情况：只有部分用户、部分地区或某个运营商异常。这更可能是线路质量、运营商路由抖动或单一入口拥塞，而不是整个 IP 被封。所以判断要建立在多点对比上，至少准备一台国内测试机、一台境外测试机，并保留客户端日志。结论分三类：IP 层封锁、端口或协议层干扰、非封锁类故障。后面每一步都是在这三类之间缩小范围。

区分封锁、配置与网络问题的判断逻辑

可以按"看到 A → 判断 B → 下一步 C"的思路处理。国内 ping 和 TCP 全部不通，境外正常，判断为 IP 层封锁，下一步确认是否整段 IP 受影响，再决定换 IP 还是调整入口。国内 ping 通，但节点端口 TCP 超时，境外端口正常，判断为端口级封锁，可以换端口验证。TCP 三次握手成功，但 TLS 握手阶段被重置或长时间无响应，判断为 SNI 或协议特征被干扰，下一步检查伪装域名和传输配置。

如果境内外都无法建立 TCP 连接，先查服务端：进程是否在监听，云厂商安全组和本机防火墙是否放行，近期是否改过配置。如果只是部分时段丢包高、延迟大，用 mtr 看哪一跳开始丢包，更可能是线路拥塞，换线路比换 IP 更有效。还要注意时间相关性：每晚高峰集中失效、白天恢复，多数是质量问题；从某个时间点起持续不通，更像封锁。把现象、时间、运营商和测试位置一起记录下来，后续分层定位会轻松很多。

DNS、SNI、TLS、客户端与服务端单节点排查步骤

针对单个节点，建议按以下顺序执行，每一步只验证一个变量： 1. DNS：在国内机器执行 nslookup 节点域名，对比境外解析结果。IP 不一致或解析到明显无关的地址，说明可能存在 DNS 污染，客户端可改用 IP 或可信 DoH 验证。 2. 端口连通：用 nc -zv IP 端口 或 tcping 分别从国内和境外测试，区分 IP 层和端口层问题。 3. TLS 与 SNI：执行 openssl s_client -connect IP:443 -servername 你的域名，观察是否完成握手、证书是否过期、域名是否匹配。出现 connection reset 而境外正常，重点怀疑 SNI 干扰。 4. 服务端：执行 ss -tlnp 确认监听端口，用 journalctl -u 服务名 -n 100 查看是否有认证失败、证书加载错误或 UUID 不匹配。 5. 客户端：核对订阅是否为最新、系统时间误差是否过大、传输参数是否与服务端一致。时间偏差会导致部分协议校验失败。

只有前四步都排除后，才把故障归因为封锁，避免把配置错误误当成被墙。

修复后的覆盖验证：多运营商、多时段确认结果

换 IP、改端口或调整 SNI 之后，不要只用自己的一台设备测一次就结束排查。至少找电信、联通、移动三个网络的探测点分别执行 nc -vz -w 5 入口IP 443，确认 TCP 能否建连。然后用 openssl s_client -connect 入口IP:443 -servername 你的SNI 检查握手能否完成、证书链是否正确。同一命令在境外机器上也跑一遍作为对照。

判断逻辑如下。境外通、国内全线超时，说明更像 IP 级封锁，下一步要换入口 IP。TCP 能通但握手阶段出现 connection reset by peer，说明更像协议特征或 SNI 被识别，下一步检查传输层配置。只有某一个运营商失败，属于区域性问题，可以先把该运营商用户引导到其他入口。客户端日志里的 i/o timeout 和 EOF 也要按运营商分组统计，不能混在一起看。另外，部分封锁会延迟生效，建议在晚高峰和次日各复测一次，连续 24 到 72 小时稳定后再视为恢复。

失败边界：哪些情况靠自助手段解决不了

自助排查能解决的，主要是配置错误、证书过期、端口冲突、DNS 解析异常和单个节点故障。被封锁的 IP 无法由运营者自行解封。换 IP 只是绕开当前状态，并不会消除导致封锁的原因。

出现下面几种信号时，应停止机械地反复换 IP。第一，新 IP 上线几天内再次失效，且总是同一批入口先出问题。这通常意味着暴露面没有收敛，例如订阅被外传、入口 IP 直接写在公开订阅里、多个入口落在同一网段或同一 ASN。第二，入口正常但落地频繁不可达，问题已经从入口层转移到了源站暴露。第三，只能从用户反馈中被动发现故障，缺少分运营商的持续探测，每次都要事后补救。第四，手工改配置牵涉几十个节点，改一次就要停机同步面板和订阅。到了这一步，单节点层面的修补收益会越来越低，需要从架构层面重新划分入口、中转和后端的职责。

长期架构与服务适用边界：入口、转发、后端解耦

长期思路是让三层各自可替换。入口层使用多个分散在不同网段、不同供应商的 IP，只负责接收连接，失效后可以快速下线替换。中转层负责把流量转发到后端，同时隔离入口与落地。落地源站不直接暴露给用户，以降低源站被关联封锁的风险。在这个架构上，再配合分运营商的健康探测和订阅侧的切换策略，并在 XBoard/V2Board 中批量维护节点信息。这样某个入口出问题时，影响面可以控制在单层、单线路之内。

如果你遇到的是多个入口或中转频繁失效、换 IP 后短期内反复出现，或者需要区分入口、中转与落地故障并设计切换方案，可以参考 Manguo Labs 的机场高可用入口解决方案（https://manguolabs.com/node-firewall/）。该方案覆盖多线路规划、批量部署，以及客户端检查与故障排查。如果只是单个客户端配置写错或证书过期，按前文步骤自查即可，没有必要上架构方案。任何方案都只能降低风险、缩短恢复时间，无法保证入口永远不被封锁。

什么时候这已经不是单点配置问题

如果你已经按上面的步骤排查过，确认不是单节点配置问题，而是入口或中转反复失效、换 IP 也撑不了多久，那么需要的是重新规划入口层和切换方案，而不是继续逐台修。这类场景可以参考 Manguo Labs 的机场高可用入口方案，先梳理现有链路，再评估改造的范围和边界。

Manguo Labs 能提供什么

Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。

本文面向机场运营者的节点可用性排查。问题一旦超出单个节点的配置，比如多个入口或中转频繁失效、换 IP 后短期内又出问题、需要区分各层故障并设计切换方案，就和 Manguo Labs 机场高可用入口解决方案的服务范围一致。该方案提供入口、中转与落地链路的高可用规划和故障排查。

适合这些情况

• 多个入口或中转频繁失效，单节点修复后很快又出问题
• 换 IP 后短期内反复被封，需要排查根因
• 需要区分入口、中转与落地的故障，并设计自动或手动切换方案

查看机场高可用入口解决方案 →

常见问题

总结与下一步

排查是否被墙，核心是“对比加分层”。境内外对比，用来区分封锁和服务端故障；DNS、SNI、TLS 逐项检查，用来区分封锁和配置错误；入口、中转、落地逐跳测试，用来定位故障在哪一层。换 IP、换端口只是临时手段，有效时间有限。如果反复失效，就要排查源站暴露和单点入口的问题，转向入口、转发、后端解耦，并配合多线路切换的长期架构。

需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。