节点“被墙”还是配置出错：先做一次对比判断
很多机场运营者听到用户说“节点全挂了”，第一反应是被墙。被墙对比的核心，是把同一节点在国内和境外两侧的表现放在一起看。境外网络能正常握手，而国内多个运营商同时超时，才更接近封锁。两侧都失败，多半是服务端进程、证书或配置有问题。只有部分地区或单一运营商失败，更像线路质量问题或局部干扰。
直接判断可以看三个信号。第一，国内 ping 和 TCP 端口是否同时不通，而境外正常。第二，节点是否换 IP 后恢复，过一段时间又失效。第三，同机房其他 IP 是否也受影响。如果只是某个客户端报错，换订阅或更新内核后就恢复，通常与封锁无关。先确认问题属于哪一类，再决定是换 IP、改配置还是调整线路，避免盲目重建节点，浪费 IP 资源和排查时间。
区分封锁、配置与网络问题：看到什么现象对应什么判断
看到国内 tcping 端口超时、ICMP 也不通，而境外探测正常，可以判断为疑似 IP 级封锁。下一步是记录发生时间，用同机房备用 IP 验证，不要急着改协议配置。看到 TCP 能连通，但 TLS 握手被重置，curl 报 Connection reset by peer 或 SSL_ERROR_SYSCALL，可能是 SNI 或流量特征被干扰，也可能只是证书过期。这时先在境外用相同参数复测，排除证书问题。看到境内外都返回 connection refused，说明端口没有服务在监听，属于服务端配置或进程问题，应检查 systemctl status 和监听端口。
看到晚高峰丢包高、白天正常，判断为线路拥塞而不是封锁。可以用 mtr 观察丢包从哪一跳开始，再决定是否更换线路或增加中转。网络问题和封锁最容易混淆。关键差别在于：封锁通常持续存在且境外不受影响，拥塞则有明显的时段规律。
单节点排查顺序：DNS、SNI、TLS、客户端与服务端
1）DNS：在国内和境外分别执行 dig node.example.com，比对解析结果。国内返回异常 IP 或无响应，可能是 DNS 污染，可以改用可信 DNS 或直连 IP 验证。 2）SNI 与 TLS：执行 openssl s_client -connect IP:443 -servername node.example.com，确认证书链、有效期与 SNI 是否匹配。境外成功而国内被重置，倾向于特征干扰。 3）服务端：用 ss -tlnp 确认端口在监听，用 journalctl -u 服务名 查看握手失败或启动报错，同时检查防火墙和安全组是否放行。 4）客户端：核对 UUID、传输协议、path、alpn 等字段与服务端一致。系统时间偏差过大也会导致部分协议认证失败。 5）交叉复测：换一个客户端、换一个网络环境再测，结果一致才下结论。
单节点逐层确认后，如果仍然只有境内失败，再进入入口、中转、落地的分层定位，判断失效发生在哪一段链路。
修复后的验证：用多点对比确认结论
修复或切换之后，不要只凭一次能连上就下结论，应该用同一套对比方法复测。第一步，在国内至少两个不同运营商网络（例如家宽和手机流量）对入口执行 ping 与 tcping，记录丢包率和 TCP 握手结果。第二步，在海外 VPS 上对同一 IP 和端口执行 curl -v，或执行 openssl s_client -connect IP:443 -servername 你的SNI，确认服务端本身正常。第三步，把客户端日志级别调到 debug，观察是否仍出现 i/o timeout、connection reset 或 TLS handshake 失败。
判读逻辑如下。国内多个网络都能握手，海外也正常，说明本次问题已缓解，继续观察 24 到 72 小时。只有某一个运营商失败，更像是该线路的路由或 QoS 问题，不是整体被墙。海外正常、国内全部超时，并且换端口仍然无效，说明入口 IP 大概率被封锁，应该切换入口，不必继续调整配置。建议把每次复测按时间、网络、入口、现象记录成表，方便之后对比。
低成本手段的失败边界
换端口、换 IP、改 SNI、换协议这类低成本手段，能解决的是单个入口暴露或单个配置错误。它们的边界很清楚：如果新 IP 上线后几天内又出现"国内超时、海外正常"的同样模式，问题就不在这个 IP 本身，而在暴露路径。常见原因有：订阅里直接写入了落地 IP，面板域名与节点共用同一个 IP，或者流量特征长期不变。这种情况下继续换 IP 只是重复消耗资源。
另一类边界是多层链路混在一起。入口、中转、落地任何一层出问题，用户看到的都是"节点不通"。如果没有逐层的对比数据，只改客户端配置或只重启服务端，很容易把网络问题误判为配置问题，或者反过来。另外，部分时段性干扰在敏感时期会扩大范围，单节点自助排查覆盖不了这种情况，任何手段也都无法保证长期有效。
长期架构思路与服务适用边界
长期思路是把入口、转发和后端解耦。用户只接触可以随时替换的入口层，入口经中转连到落地，落地 IP 不出现在订阅和面板中。每一层都准备备用资源，再配合健康检查和订阅侧的切换策略，这样单个入口失效时，影响范围是可控的。使用 XBoard/V2Board 的运营者，还应检查面板域名、节点地址和回源配置是否暴露了源站。
Manguo Labs 的机场高可用入口解决方案面向的正是这类场景：多个入口或中转频繁失效，换 IP 后短期内又反复出现，或者需要区分入口、中转与落地故障并设计切换方案。它提供的是链路高可用规划和故障排查，有助于降低源站暴露风险，但不承诺任何节点不被封锁。如果只是单个节点配置错误，按前文步骤自查通常就够了。当问题跨越多层并且反复出现时，可以在 https://manguolabs.com/node-firewall/ 了解方案细节，或通过 Telegram 咨询具体情况。
什么时候这已经不是单点配置问题
如果按上述步骤排查后，问题仍集中在单个节点配置，自行修正即可；若入口、中转、落地反复失效，或已换过多次 IP 仍短期复发，问题已跨越单节点配置，可以参考 Manguo Labs 的机场高可用入口方案，从链路分层和切换设计角度评估。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
本文的判断方法适用于单节点自查；当被墙对比结果显示多个入口或中转频繁失效、换 IP 后短期内反复出现，或需要区分入口、中转与落地故障并设计切换方案时，与 Manguo Labs 机场高可用入口解决方案的入口、中转与落地链路高可用规划和故障排查范围对应。
适合这些情况
- 多个入口或中转频繁失效的机场运营者
- 换 IP 后短期内反复出现封锁的场景
- 需要区分入口、中转与落地故障并设计切换方案的团队
常见问题
国内 ping 不通、境外 ping 正常，是否一定是 IP 被墙？
可能性较高，但不是唯一结论。部分云厂商或机房会对 ICMP 做限制，也可能存在单一运营商路由问题。建议同时用 tcping 或 nc -vz 测试服务端口，并分别从电信、联通、移动线路检测；若多个运营商 ICMP 与 TCP 都不通、境外均正常，再判断为 IP 封锁更稳妥。
端口能通但客户端一直超时，属于被墙还是配置问题？
先看客户端日志。若出现 TLS handshake timeout 或连接被重置，且境外用同一配置正常，倾向协议特征或 SNI 被干扰；若出现 certificate、uuid、invalid user、alpn 不匹配等报错，基本是配置问题。可用 openssl s_client -connect IP:443 -servername 域名 检查证书和握手是否完成。
换 IP 后能用几天又失效，说明什么？
说明问题不在单个 IP，而在暴露方式或流量特征：例如入口 IP 直接写在订阅里被大量分发、协议特征明显、落地源站直接对外。此时继续换 IP 只能短期缓解，应考虑把入口、转发与后端解耦，并准备多线路切换。
如何判断故障出在入口、中转还是落地？
从后往前逐段测：先在中转机上直接连接落地端口，确认落地正常；再从国内测试中转端口；最后测试入口。哪一段开始失败，故障就落在那一层。同时对比服务端日志中有无对应来源的连接记录，有握手无流量和完全无记录指向的层级不同。
总结与下一步
被墙对比的关键是在国内外、多运营商之间对照 ping、TCP 端口、TLS 握手和客户端日志，把 IP 封锁、端口或协议干扰、配置错误和线路故障区分开，再按入口、中转、落地逐段定位。换 IP、换端口、调整 SNI 等临时手段可以恢复使用，但若同类故障反复出现，根因通常在入口暴露和架构耦合，需要多入口、转发层与后端解耦的长期设计。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →