节点被墙为什么：先给出直接判断
节点“被墙”，通常是入口 IP、端口或某类流量特征被识别后遭到阻断。常见表现是国内访问 TCP 握手超时、连接被重置或严重丢包，而境外探测同一地址仍然正常。被墙的原因大致有几类：协议或 TLS 指纹与常见网站差异明显；单个 IP 长期承载大量用户，流量模型异常；入口 IP 或订阅域名被公开传播，扫描后被标记；同一机房网段曾被滥用，整段信誉下降；敏感时期批量封锁力度加大。
判断时先看影响范围。多个省份、多家运营商的用户同时断连，而境外连通正常，大概率是封锁。只有个别用户异常，更可能是客户端配置或本地网络问题。境外也不通，就应先查服务器、机房或防火墙。第一步是确认问题出在哪一层，不要急着换 IP：如果根因是配置或暴露方式，换 IP 后往往很快会再次失效。
区分封锁、配置与网络问题
很多“被墙”其实是配置错误或线路质量问题，可以按“看到 A → 判断 B → 下一步 C”快速分流。ping 不通但 TCP 443 可以连通，说明只是 ICMP 被限制，不能据此认定被墙，应继续测试 TCP 与 TLS。国内 TCP 普遍超时而境外正常，判断为 IP 级封锁，可以先查看同网段其他 IP 的状态。只有某个端口不通、换端口后恢复，属于端口级阻断，要注意新端口可能很快被再次识别。TCP 能建立但 TLS 握手阶段被重置，多与 SNI 或流量特征干扰有关，应检查伪装域名与指纹配置。
服务端日志完全没有新连接进来，说明流量在入口之前就被拦截，可能是封锁，也可能是云厂商安全组拦截。日志里有连接但出现认证失败、解密错误，基本是配置问题，比如 UUID、传输方式或时间不同步。晚高峰丢包严重、白天正常，更像国际出口拥塞，属于线路质量问题，应评估是否需要中转，而不是反复换 IP。
DNS、SNI、TLS 与客户端服务端的单节点排查步骤
下面的步骤以示例入口 203.0.113.10:443 为例，建议在国内和境外各准备一台测试机，对比执行：
1. 测试端口连通：执行 nc -vz -w 5 203.0.113.10 443。国内超时、境外成功，指向封锁；两边都失败，先查服务进程和安全组。 2. 定位丢包位置：执行 mtr -rwc 50 203.0.113.10。丢包从国际出口附近开始并持续到末跳，多为阻断或拥塞；只有中间某一跳丢包、末跳正常，可以忽略。 3. 检查 DNS：分别执行 dig +short node.example.com @223.5.5.5 和 dig +short node.example.com @1.1.1.1。结果不一致或返回无关 IP，说明存在污染，应改用 IP 直连或加密 DNS 验证。 4. 检查 SNI 与 TLS：执行 openssl s_client -connect 203.0.113.10:443 -servername www.example.com，再换一个 SNI 对比。出现 Connection reset by peer 或拿不到证书，说明握手阶段受到干扰。
5. 检查服务端：用 ss -tnp | grep :443 确认监听，用 journalctl -u xray -n 100 查看报错，同时确认时间同步。VMess 在时间偏差约 90 秒以上时可能认证失败。 6. 核对客户端：确认版本、UUID、传输协议、路径和 ALPN 与服务端一致，并排除本地代理规则冲突。
处理后的覆盖验证：别只看自己能连上
换 IP、改端口或调整 SNI 后，只在本地测一次就判定“已恢复”，很容易误判。建议按以下步骤验证：1. 在电信、联通、移动等不同运营商网络分别执行 tcping 入口IP 443，确认 TCP 能连通；2. 执行 openssl s_client -connect 入口IP:443 -servername 你的SNI，确认握手完成、证书链正确；3. 执行 mtr -T -P 443 入口IP，观察丢包从哪一跳开始；4. 用客户端访问一个外网地址，确认落地出口 IP 与预期一致。
判断逻辑如下：多个运营商 TCP 都通、握手正常，说明入口本身可用。只有单一运营商超时，更像区域性阻断或线路质量问题，下一步应替换该线路的入口，不需要全量换 IP。TCP 能通，但握手中断或出现 connection reset，应回查 SNI 与证书配置。验证不是一次性的，建议连续观察 24 到 72 小时，记录每次失效的时间点和影响范围。这些记录是后面分析“被墙为什么反复出现”的依据。
临时办法的失败边界：换 IP 为什么越换越快
换 IP、换端口、换伪装域名属于低成本自救，适合偶发的单节点失效。出现以下现象时，说明已经超出临时处理的边界：新 IP 上线几天甚至几小时就再次不可用；多个入口在相近时间段同时失效；换了机房和服务商，失效规律依旧。这时问题通常不在某一个 IP，而在暴露方式本身。
常见根因包括： - 订阅内容直接写入源站或落地的真实 IP，订阅一旦被转发，所有地址都会随之暴露。 - 入口与后端是同一台机器，入口被识别后，后端也跟着失效。 - 所有节点使用相同的端口、证书和配置模板，流量特征高度一致。 - 没有切换预案，只能被动等待用户反馈。
如果看到“换了就好、好了又坏”的循环，应停止单纯堆 IP，转而梳理入口、中转、落地各层分别暴露了什么。否则换 IP 的成本会持续上升，可用性却不会明显改善。
长期架构思路与服务适用边界
长期方案的核心是解耦，分三层来看： - 入口层：只负责接入，可以批量部署、按运营商分组，失效时单独替换。 - 转发层：承担中转与分流，隐藏后端真实地址。 - 落地层：只接受来自转发层的连接，以降低源站暴露风险。
订阅中只下发入口地址，不下发落地地址。再配合多线路冗余和健康检查，单个入口失效时，影响范围就比较可控。如果使用 XBoard/V2Board 管理节点，节点信息应与这套分层对应，避免把后端 IP 写进用户可见的配置。需要说明的是，任何架构都不能让入口不再被识别，目标是缩小影响范围、缩短恢复时间。
如果只是单节点配置错误，按前文自查即可，不必引入复杂方案。如果多个入口或中转频繁失效、换 IP 后短期内反复出现，或者难以区分入口、中转与落地的故障，可以参考 Manguo Labs 的机场高可用入口解决方案。该方案提供入口、中转与落地链路的高可用规划和故障排查，详情见 https://manguolabs.com/node-firewall/ 。
什么时候这已经不是单点配置问题
如果按本文步骤排查后，确认问题不在单个节点配置，而是多个入口或中转频繁失效、换 IP 后很快又出现同样问题，就需要从架构层面重新规划入口、转发和后端，这时可以参考成熟的高可用方案。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
本文针对的是机场运营者遇到的入口反复失效问题。Manguo Labs 的机场高可用入口解决方案提供入口、中转与落地链路的高可用规划和故障排查，适合问题已经超出单个节点配置、需要区分各层故障并设计切换方案的场景。
适合这些情况
- 多个入口或中转频繁失效的机场运营者
- 换 IP 后短期内又反复失效的场景
- 需要区分入口、中转与落地故障并设计切换方案的团队
常见问题
怎么快速判断节点是真的被墙，还是配置出了问题？
在国内和境外各测一次 ping、TCP 端口（如 nc -vz IP 443）和 TLS 握手（openssl s_client -connect IP:443 -servername 域名）。境外都正常、国内 ICMP 或 TCP 超时，比较像 IP 或端口被封；两边都失败，多半是服务端进程、防火墙或证书问题；TCP 能通但握手时被重置，就要重点查 SNI 和协议特征。
被墙为什么换了 IP 过几天又不行？
常见原因有：新 IP 仍然配合同一个已经暴露的域名或协议特征使用；订阅被大范围分发，入口地址很快被收集；所有用户都集中在少数入口上，流量特征明显；入口和落地强绑定，换 IP 没有改变暴露面。只换 IP 属于临时处理，能不能撑下去取决于根因有没有消除。
只有部分用户连不上，也算被墙吗？
不一定。如果只是某个运营商或某个地区失败，更可能是线路质量、运营商 QoS 或局部 DNS 污染，不是全面封锁。可以按运营商统计失败率，并让用户提供客户端日志，比如 i/o timeout、connection reset、TLS handshake failure，再对照入口、中转和落地逐层排查。
域名被污染和 IP 被封该怎么处理？
如果 dig 查询返回的解析结果异常，而直接连 IP 正常，属于 DNS 问题：可以换成没被污染的域名，或者检查客户端的 DNS 设置。如果直接用 IP 连接也在 TCP 层超时，说明 IP 本身不可达，需要更换入口 IP 或切换到备用入口。两种情况处理思路不同，不要混在一起。
总结与下一步
被墙为什么会发生、为什么会反复？关键是先分清三类问题：封锁、配置错误和网络故障。可以用国内外对照测试，按 DNS、SNI/TLS、客户端、服务端单节点的顺序排查，再按入口、中转、落地分层定位。换 IP、换端口只是临时手段，并且有明确边界。反复失效的根因通常在于入口暴露集中、入口和后端耦合。长期来看，应把入口、转发和后端解耦，并设计多线路切换方案。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →