被墙怎么选择：先定位失活层级，再决定换入口还是换落地
被墙怎么选择，多数人的第一反应是换机场或换节点，但真正决定后续是否有效的，是先判断失效发生在链路的哪一跳。典型链路是：客户端 → 本地网络与 DNS → 入口（域名或 IP）→ 中转 → 落地节点。其中任意一环被干扰，客户端看到的现象都可能是「全部超时」，此时只换落地节点常常没有意义。
一个可用的判断顺序是：如果所有节点在同一分钟内集体失效，优先怀疑入口地址或域名层面；如果只是部分节点失效、其余正常，更可能是某个入口 IP 或某个落地端口被针对性干扰；如果换到手机热点后恢复正常，问题大概率在本地网络或运营商侧。看到「集体失效且换网络无效」→ 判断入口层受干扰 → 下一步先记录失效时间点、涉及节点和当时使用的端口，再决定是切备用入口还是切落地。
区分封锁、配置错误与本地网络问题
这三类问题的表现并不相同。封锁类干扰通常在连接建立到一定阶段后介入，表现为 TLS 握手失败或握手完成后不久连接被重置；配置类错误往往更直接，客户端明确报域名解析失败或端口连不上；本地网络类问题的特征是同一份配置换个网络就正常。 可以用几条命令快速分层： dig +short 你的域名 curl -v --connect-timeout 5 https://入口地址:入口端口 openssl s_client -connect 入口地址:入口端口 -servername 你的域名 -brief 看到 TCP 三次握手成功但 TLS 阶段返回 EOF 或 reset → 判断是 SNI 或流量特征被识别，而不是配置写错 → 下一步用 IP 直连或更换端口做对照测试；看到 could not resolve host → 判断是 DNS 问题 → 下一步换公共 DNS 或在 hosts 中临时固定记录；看到 connection refused → 判断服务端未监听或被防火墙拦截 → 下一步去入口机核对监听状态与安全组规则。
单节点排查的有序步骤：DNS → SNI → TLS → 客户端 → 服务端
1. 记录基线：在可用状态下保存当时的端口、SNI 和日期，失效时用于对比。 2. 解析检查：dig +short 域名 @1.1.1.1，返回为空或明显异常地址，问题在 DNS 层。 3. 端口检查：nc -vz 入口地址 入口端口，不可达则先查安全组与防火墙规则。 4. SNI/TLS 检查：openssl s_client -connect 入口:端口 -servername 域名，若不带 SNI 可通、带 SNI 不通，指向 SNI 层干扰。 5. 客户端检查：核对系统时间、客户端版本与内核协议支持；日志出现 handshake failure 时，先排除本地时间偏差再怀疑服务端。 6. 服务端检查：ss -lntp 看监听，journalctl -u 服务名 -n 50 看近期日志，确认证书未过期、进程未被 OOM 终止。
判断逻辑：第 2 至第 4 步都正常而客户端仍失败，换一台设备和另一个客户端对照；若多台设备、多个网络同时失败，问题在服务端或入口，而不是你的客户端。
怎么验证"换入口/换节点"是否真的解决了问题
判断一次切换是否有效，不能只看客户端是否连上。建议按入口、中转、落地三段分别验证，每段有独立的成功标准。
先直连入口端口，例如 nc -vz 入口IP 端口，返回 succeeded 说明入站可达，超时则先排除入口层。再用 curl -v --resolve 域名:端口:入口IP https://域名/ 观察 TLS 握手，若停在 Client Hello 无响应，问题通常在 SNI 或中间链路，不在落地节点。接着在任何一台能出网的机器上用 curl -x http://127.0.0.1:7890 -I https://www.gstatic.com/generate_204 测出口，返回 204 表示这一段通。最后回到客户端看日志：测速超时、握手失败、连接被重置分别对应网络层、TLS 层与应用层，处理顺序不同。
看到 A → 判断 B → 下一步 C：只有部分客户端失败，先怀疑本地 ISP 或本地 DNS，换网络复测；所有客户端同时失败，优先查入口 IP 与端口；入口通而落地不通，查中转的带宽、防火墙与会话数限制。每次只变更一层并记录前后结果，否则后续无法归因。
哪些情况换节点解决不了：失效边界的几种典型
有几种情况换节点或换 IP 只能缓解，不能消除。一是域名层被解析屏蔽：IP 换了、域名没换，客户端仍拿不到正确地址，现象是解析失败或解析到异常地址，而不是连接超时。二是协议与流量特征被识别：链路可达、TLS 也能完成，但连接在建立后被持续重置或传输中段中断，测速时表现为小流量可用、大流量失败。三是本地网络自身问题，例如运营商 QoS、单位出口策略或本地 DNS 污染，换节点后仍旧失败，容易误判成节点被封。四是订阅或账号层问题，例如订阅链接失效、权限到期，表现为所有节点一起不可用。
判断顺序上，先把"全网都失败"和"只有某些客户端失败"分开，前者看服务端，后者看本地。若换 IP 后短期内再次失效，说明触发条件与地址本身关系不大，可能是入口特征或链路中间环节被针对，此时继续单点换 IP 的收益很低。需要明确的是，任何方案都无法承诺长期不被识别；能做到的是缩短发现到切换的时间、缩小影响范围、保留可回溯的变更记录。
长期架构：入口、转发与后端解耦，以及它适用的边界
长期思路是把入口、转发与后端解耦。入口层准备多个相互独立的入口（不同机房或不同线路方向），每个入口配可用性探测，探测失败先告警再自动摘除，避免人工响应延迟。域名和证书作为独立配置项管理，入口更换时只切换解析与订阅下发，不动落地。XBoard/V2Board 一类面板里，可以按入口组与落地组分发订阅，出问题时只对受影响分组重新下发，减少用户侧手改配置。
何时需要这套设计，是有边界的。单节点证书过期、客户端版本过旧、某个节点配置写错，属于先自查就能解决的问题，上架构方案只会增加复杂度。当失效跨越多个入口或中转、换 IP 后短期内反复出现、故障点无法在单层定位时，分层与切换设计才有意义。Manguo Labs 的机场高可用入口解决方案面向的正是这类场景，覆盖入口、中转、落地的链路规划与故障排查，也包含多线路与批量部署、客户端检查与故障排查。是否需要投入取决于失效频率和你的运维成本，可以先到 https://manguolabs.com/node-firewall/ 对照自身现象确认边界。
什么时候这已经不是单点配置问题
如果排查结果是：失效跨越了多个入口或中转、换地址后短期内又出现、每次恢复都要人工操作，那问题已经不在单台节点的参数里，而在入口、中转、落地三层绑得太紧。这时继续在单点上换端口、换协议，投入产出比会越来越低。把入口做成可批量替换的域名层、中转做成可切换的转发层、落地与入口分离，再配合客户端侧的检查清单，才是这一层级更合适的处理方向。
Manguo Labs 能提供什么
Manguo Labs 为机场运营者提供入口、中转与落地链路的高可用规划和故障排查方案。
文章主体解决“被墙怎么选择”的判断问题：分层定位、低成本处理与边界说明都不依赖任何产品。只有当结论落在“失效跨越单个节点、入口或中转反复失效、换 IP 后短期内重现、需要区分入口与落地并设计切换”这一层时，Manguo Labs 的机场高可用入口解决方案才作为可评估的下一步出现，包含多线路与批量部署、降低源站暴露风险、XBoard/V2Board 环境下的入口规划，以及客户端检查与故障排查配合。文中不宣称该方案能消除封锁，只说明它针对的是架构耦合与切换效率问题。
适合这些情况
- 入口或中转在同一时间窗外反复失效，换地址后短期内重现
- 需要明确区分入口、中转与落地三层故障，而不是只盯单台节点
- 希望入口可批量替换、中转可切换后端，减少人工换 IP 的依赖
- 运营 XBoard/V2Board，需要入口规划与客户端排查配合
常见问题
换 IP 之后几天又失效，一定是被墙吗？
不一定。先看失效范围：只有单个用户连不上，多半是客户端配置、订阅未更新或本地网络问题；同一入口下多名用户同时掉线，才更像入口被针对。再看形态：域名解析返回异常 IP 属 DNS 污染，TCP 能握手但 TLS 阶段中断更像 SNI/TLS 干扰，端口连接直接超时是 IP 或端口层封锁，三类处理方式不同。如果换 IP 后总是在相近时间窗内再次失效，说明被针对的是入口特征而非某个地址，继续轮换地址收益有限。
怎么快速区分 DNS 污染、SNI 阻断和端口封锁？
用同一台机器按顺序验证。第一步 dig +short 域名，与公共解析（如 1.1.1.1）结果比对，明显不一致优先怀疑污染。第二步 nc -vz 入口IP 端口 测 TCP 可达性，超时说明 IP 或端口层不通。第三步 TCP 通但 curl -v https://域名 卡在 TLS 握手或出现 reset，更可能是 SNI/TLS 层干扰。三层都正常而客户端仍失败，问题基本回到客户端配置、协议参数或本地分流。
同一入口只有部分用户掉线，该先查什么？
客户端侧先查订阅是否更新到最新地址、系统时间偏差是否过大（偏差会导致 TLS 握手失败）、本地分流规则或常驻代理是否冲突。服务端侧看该时间段连接日志中握手失败的比例、失败方式，以及带宽和并发连接是否打满。若只有零星用户异常，按单节点排查即可；若日志显示同一入口整体握手成功率下滑，才回到入口层面处理。此阶段不需要改动架构。
多入口、中转和落地要解耦到什么程度才算够？
至少满足三点：客户端拿到的应是入口域名而非固定 IP，入口按线路批量替换时不必改订阅；中转层能按可用性切换后端，单台中转失效时流量仍有出口；入口与落地不共用同一台机器的同一地址，避免一次封锁同时打断两层。判断标准很直接——换掉任意一层时，其余层是否需要人工改动，需要改动的越多，耦合越重。
自助换端口、换协议能撑多久，什么时候该考虑高可用方案？
换端口、调整 SNI、临时加一层中转、启用备用域名，都属于把服务先拉回可用的短期手段，它们不处理反复失效的根因：入口特征固定、单点依赖强、切换靠人工，同一次封锁往往会重复生效。当失效已经跨多个入口、短期内多次出现，而且每次恢复都依赖人工换地址时，说明问题超出单节点配置范围，此时再评估入口、中转、落地解耦与批量部署更合适。
总结与下一步
被墙怎么选择，本质是先判断再决策：用 DNS 比对、TCP 连通性、TLS 握手三个检查点界定失效层级，用“单人还是多人、单节点还是多入口”界定范围，再匹配处理手段。零星、单层、一次性失效适合自助排查与临时调整；跨层、跨入口、反复出现的失效则指向入口与中转落地耦合过重，需要按可替换、可切换、可批量部署的思路重新规划。全篇不承诺任何方案能永久免疫封锁，只给出可复现的判断逻辑与选型边界。
需要进一步评估时，可先查看机场高可用入口解决方案，并参考更多技术文章。
继续阅读
了解 机场高可用入口解决方案 →