防墙常见问题：节点失效如何判断封锁、配置还是网络故障

用户现象与直接判断

防墙常见问题里，最常见的现象是：用户反馈“节点全红”“能连但打不开网页”“白天正常晚上断”，运营者换了 IP 后几天又复现。直接结论是：不要一看到超时就认定被墙。真正的封锁通常表现为同一入口 IP 在国内多个运营商同时不可达，而海外探测正常。如果只有部分用户、部分客户端或某一协议失败，更可能是配置、证书或线路质量问题。

判断时先收集三类信息：失败的入口地址与端口、用户所在运营商与地区、客户端类型及版本。然后用国内与海外两个探测点对同一入口做 ping、TCP 端口探测和 TLS 握手测试。看到国内 ICMP 与 TCP 全部失败、海外全部正常，就判断入口 IP 被封锁的可能性较高，下一步考虑切换备用入口。看到 TCP 能通但握手失败，就先查 SNI 与证书，不要急着换 IP。

区分封锁、配置与网络问题

三类问题的日志表现差异明显，可以按特征快速分流。封锁类：入口 IP 在国内全运营商不可达，或 TCP 能建立但几秒后被重置，服务端日志几乎看不到来自国内的新连接，常见于同一 IP 长期承载大流量的场景。配置类：服务端能收到连接，但日志出现 TLS handshake error、invalid user、证书不匹配或 UUID 错误，通常在修改面板、证书续期或升级内核后集中出现。网络类：延迟和丢包随时段波动，晚高峰明显恶化，换协议无效，但换一条线路后会改善。

实际排查中三类问题经常叠加，例如晚高峰丢包导致握手超时，看起来就像被封。建议用 mtr 从国内探测点连续观察十分钟以上。丢包从某一跳开始并持续到终点，说明是线路或中转问题。前面各跳正常而终点完全无响应，更接近封锁。终点可达但应用层失败，就回到配置检查。

DNS / SNI / TLS / 客户端 / 服务端单节点排查

单节点建议按固定顺序排查，每次只改一个变量。第一步查 DNS：在国内机器执行 dig 节点域名，确认解析结果与实际入口一致。第二步查端口：执行 nc -zv 入口IP 443，确认 TCP 可达。第三步查 SNI 与 TLS：执行 openssl s_client -connect 入口IP:443 -servername 你的域名，核对证书域名、有效期和证书链。第四步查客户端：确认内核版本支持所用协议，订阅里的 UUID、端口、flow 与服务端一致。第五步查服务端：用 journalctl -u xray 查看日志，确认连接是否到达。

DNS 异常时，先修正记录或改用 IP 测试。TCP 不通但服务端监听正常时，先查防火墙与安全组，再考虑封锁。握手失败时，重点查证书与 SNI。服务端完全没有日志时，问题多半出在入口之前的中转或网络。每改一处都要重新测试，才能找到真正的故障点。

处理之后如何验证：分层复测与观察窗口

换 IP、改端口或调整 SNI 后，不要只看“能连上”就结束，应按入口、中转、落地逐层复测。入口层：从电信、联通、移动至少两类国内网络执行 nc -vz 入口域名 443。端口不通而 ping 正常，多为端口或 IP 级阻断。TCP 通但 curl -v --resolve 你的SNI:443:入口IP https://你的SNI 卡在 TLS 握手，应回查证书、SNI 与 TLS 指纹。中转层：用 ss -tnp | grep 443 确认有入站连接，同时看是否建立了到落地的出站连接。落地层：在落地机本地代理执行 curl -x socks5://127.0.0.1:1080 https://www.cloudflare.com/cdn-cgi/trace，确认出口 IP 正确。

日志也要对照看。Xray 或 sing-box 中大量 i/o timeout 指向链路不通；connection reset by peer 集中在某个入口，多半是该入口被干扰；握手成功但流量为零，则查中转到落地的转发规则。验证建议保留 24-72 小时观察窗口，并记录各运营者的成功率变化。只测一次就宣布修复，往往会把下一次故障误判为新问题。

失败边界：哪些情况自助处理已经不够

自助处理能解决配置错误、证书过期、单个 IP 被阻断这类问题，但有明确边界。

看到换 IP 后几小时到几天又失效，下一步要查后端是否暴露，继续换 IP 意义不大。看到多个入口同时失效，且它们属于同一机房或同一 ASN 段，说明问题在网段层面，改端口或换 SNI 只能短暂缓解。看到订阅域名在部分地区解析结果异常，属于 DNS 污染，节点本身正常也无法使用。看到晚高峰丢包高、白天正常，更可能是运营商出口拥塞，换协议通常无效，应调整线路质量。

还有一类问题容易被忽略：源站 IP 已经出现在订阅明文、面板回调地址或证书透明日志中。这类问题可以在 crt.sh 检索自己的域名来确认。源站一旦暴露，单节点层面的任何修补都无法撤回已泄露的信息。这时问题已经变成架构问题，不再是参数问题。

长期架构与服务适用边界

长期思路是把入口、转发、后端解耦。入口层只承担接入，按可替换资源设计，坏一个就下线一个。中转层负责转发和健康检查，并在入口与落地之间隔离真实地址。落地后端不直接出现在订阅中。在 XBoard/V2Board 中，节点地址应指向入口域名或入口组。切换时只改解析或订阅下发，不动后端配置。多线路批量部署要配合统一的模板和监控，否则入口一多，排查成本会反过来变高。这套设计能降低源站暴露风险、缩短切换时间，但不能保证线路不被干扰。

如果你遇到的是多个入口或中转频繁失效、换 IP 后短期内反复出现，或者需要明确区分入口、中转与落地故障并设计切换方案，可以参考 Manguo Labs 的机场高可用入口解决方案：https://manguolabs.com/node-firewall/。如果只是单节点配置错误或个别用户客户端设置问题，按前文步骤自查通常更快，不必引入额外架构。

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

单个节点的配置错误，按本文步骤一般能自行定位和修复。如果问题已经超出单节点配置，比如多个入口或中转反复失效、换 IP 后很快又不能用，就需要从架构上规划入口、转发和后端的解耦与切换，这时可以参考成熟的高可用入口方案。

Manguo Labs 能提供什么

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

本文排查的是机场入口、中转与落地链路的可用性问题，与 Manguo Labs 机场高可用入口解决方案的范围一致：该方案为机场运营者提供入口、中转与落地链路的高可用规划和故障排查，帮助区分各层故障并设计切换方案，适合多个入口或中转频繁失效、换 IP 后短期内又出问题的场景。

适合这些情况

• 多个入口或中转频繁失效的机场运营者
• 换 IP 后短期内问题反复出现的场景
• 需要区分入口、中转与落地故障并设计切换方案的团队

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

常见问题

总结与下一步

防墙常见问题的核心是先分清封锁、配置和网络这三类原因：境内外对比探测判断是否被封，openssl 和客户端日志检查 SNI/TLS 配置，mtr 看线路质量。再按入口、中转、落地逐段验证连通性和服务端日志。换 IP、换端口、换域名能临时恢复，但如果反复失效，根因往往在源站暴露、单入口集中承载和缺少切换机制，需要把入口、转发和后端解耦，设计成可以批量替换、自动切换的结构。

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