--- title: "为什么你的节点会被封：常见触发条件分析" date: 2026-05-10 categories: - GFW 与审查 tags: - 封锁 - IP - 协议检测 - 触发条件 - 运维 excerpt: "节点被封并非随机——GFW 有一套检测逻辑和触发条件。理解这些条件帮你选择更稳定的节点。" index_img: /images/posts/node-blocking-causes.webp --- > **摘要**：节点被封是使用代理过程中最常遇到的问题。封锁并非随机——GFW 有一套检测逻辑和触发条件。理解这些触发条件，可以帮助你选择更稳定的节点，也能理解为什么某些节点比其他的更持久。 --- ## 封锁的基本逻辑 很多人认为 GFW 封锁节点是一件随机的事——今天能用，明天突然不能用，看起来毫无规律。但实际上，GFW 有一套相对系统化的封锁流程，大致遵循**检测 → 分析 → 执行**的模式。 **检测阶段**：GFW 通过部署在骨干网上的 DPI（深度包检测）设备、DNS 监控系统和主动探测器，持续扫描跨境流量中的异常信号。这些异常信号包括但不限于：协议特征不匹配、TLS 指纹异常、流量行为偏离正常模式等。 **分析阶段**：单一维度的异常通常不会直接触发封锁。GFW 会对多个维度的异常进行综合评估。例如，一个 IP 同时表现出"TLS 指纹与浏览器不匹配"和"长时间持续加密连接"两个特征，其被封锁的概率远高于只有单一异常的 IP。这种综合评分机制解释了为什么有些配置不完美的节点仍然能用——它可能只触发了一两个低权重的检测维度，尚未达到封锁阈值。 **执行阶段**：当综合评分超过阈值后，GFW 会对目标 IP 或端口采取封锁措施。执行手段包括 IP 级别的全端口封锁、特定端口封锁，或者临时性的流量干扰（如丢包、限速）。 理解这三个阶段的一个关键含义是：**GFW 并不追求百分之百消灭所有翻墙行为。** 完全阻断所有加密跨境连接在技术上不可行，在经济上也不可接受——大量外贸企业、跨国公司、科研机构依赖加密跨境连接开展正常业务。GFW 的实际目标是让翻墙行为对普通用户来说"足够麻烦"，使得大多数人因为门槛过高而放弃，同时不影响合法的跨境商业活动。 另一个需要理解的规律是：**封锁阈值会随政治周期波动。** 在敏感时期（如重大会议、特定纪念日），检测系统的阈值会显著降低——平时不会触发封锁的轻微异常，在敏感时期可能直接导致 IP 被封。反过来，日常时段的检测相对宽松，给代理工具留出了更多生存空间。 --- ## 触发条件一：协议特征被识别 这是最直接的触发条件。如果你使用的代理协议本身就有明显的流量特征，GFW 的 DPI 系统可以直接在数据包层面识别出"这是代理流量"，然后采取封锁措施。 **已被有效识别的协议**： - **裸 VMess 协议**：VMess 是 V2Ray 最早支持的协议。未经 TLS 封装的 VMess 流量在包头结构和加密模式上具有可被 DPI 捕捉的特征。GFW 自 2020 年左右开始对裸 VMess 进行大规模检测和封锁。在当前环境下，直接使用裸 VMess 的节点存活时间通常以小时到天为单位计算。 - **旧版 Shadowsocks（非 AEAD-2022）**：早期版本的 Shadowsocks 使用 stream cipher（如 aes-256-cfb），存在已知的流量特征。更关键的是，旧版 Shadowsocks 在错误处理上存在可被主动探测利用的行为差异——对合法连接和非法连接的响应模式不同，这为 GFW 的主动探测提供了明确的识别依据。 - **OpenVPN**：无论使用 TCP 还是 UDP 模式，OpenVPN 的握手过程都有非常明确的协议指纹。其 opcode 字段和密钥交换模式是公开的标准协议，GFW 可以轻松识别并阻断。在中国大陆，OpenVPN 几乎可以认为已经被完全封锁。 - **WireGuard**：尽管 WireGuard 在性能和代码简洁性上优于传统 VPN，但其握手报文使用固定的消息类型标识（Type 1/2/3/4），包大小分布也非常特征化。GFW 可以通过这些固定模式快速识别 WireGuard 流量。 - **L2TP/PPTP**：这些老旧的 VPN 协议几乎没有任何伪装能力，被封锁已久。 **影响范围**：当 GFW 通过 DPI 识别出代理协议后，可能采取两种措施——封锁该 IP 上的特定端口（如果判定代理只运行在某个端口上），或者封锁整个 IP（如果多个端口都表现出代理特征）。 **防范措施**：使用 GFW 当前无法有效识别的现代协议。在 2026 年的技术环境下，**VLESS+Reality** 和 **Shadowsocks-2022**（使用 2022-blake3-aes-128-gcm 或 2022-blake3-aes-256-gcm 方法）是抗 DPI 检测能力最强的两个方案。前者通过借用真实网站的 TLS 连接来隐藏代理特征，后者通过全新设计的加密格式消除了旧版 Shadowsocks 的所有已知特征。这两种协议均已在 [Xray-core](https://github.com/XTLS/Xray-core) 中得到完善支持。 --- ## 触发条件二：TLS 指纹异常 即使你的代理流量被 TLS 加密包裹，TLS 握手阶段的明文信息仍然可以暴露你使用的客户端类型。这就是 TLS 指纹检测的原理。 **问题的本质**：当代理客户端发起 TLS 连接时，它发送的 Client Hello 消息包含了加密套件列表、扩展列表、椭圆曲线偏好等参数。这些参数的具体组合因 TLS 实现库的不同而各异。大多数代理工具使用 Go 语言开发，而 Go 标准库 crypto/tls 产生的 TLS 指纹与 Chrome、Firefox 等主流浏览器截然不同。 **GFW 如何利用这一点**：假设你的代理连接 SNI 指向 apple.com，但 TLS 指纹显示客户端是一个 Go 程序而非浏览器。正常用户不会用 Go 程序访问 apple.com。这种 SNI 与客户端指纹之间的矛盾是一个非常强的代理特征。GFW 可以据此将这条连接标记为可疑，甚至直接阻断。 **Go/Rust TLS 库的指纹问题**：Go 语言的 crypto/tls 和 Rust 语言的 rustls 库各自有独特的 TLS 指纹，两者都与主流浏览器明显不同。由于这些编程语言在代理开发领域的广泛使用，它们的 TLS 指纹已经被 GFW 熟知并纳入检测规则。 **防范措施**： - **使用 Reality 协议**：这是最彻底的解决方案。Reality 不尝试模拟浏览器指纹，而是直接与真实目标网站交互，让 GFW 看到的 Server Hello 和证书来自真实网站。即使 Client Hello 使用 uTLS 模拟的指纹存在微小偏差，Reality 的整体握手行为仍然与真实 TLS 连接高度一致。 - **使用 [uTLS](https://github.com/refraction-networking/utls) 配置 Chrome 指纹**：如果不使用 Reality，至少应当在代理客户端配置中启用 uTLS 并选择 Chrome 指纹。在 Xray 或 Sing-box 的配置中设置 `"fingerprint": "chrome"` 可以显著降低 TLS 指纹层面的检测风险。Chrome 是全球市场份额最高的浏览器，模拟 Chrome 指纹在统计上最"普通"。 --- ## 触发条件三：流量模式异常 即使你的协议伪装完美、TLS 指纹无懈可击，长期的流量行为模式仍然可能暴露代理使用。这是 GFW 检测体系中最难对抗的一个维度，因为它不依赖协议层面的任何特征，而是从宏观的统计角度分析流量行为。 **GFW 关注的流量行为特征**： - **单一源 IP 到单一海外 IP 的持续加密连接**：正常用户的上网行为是分散的——浏览不同的网站、连接不同的服务器，连接频繁建立和断开。但一个代理用户的流量模式是：所有加密流量都指向同一个海外 IP，且连接长时间保持活跃。这种"一对一长连接"模式在宏观上非常显眼。 - **异常时段的大流量传输**：凌晨 2 点到 5 点之间，一个家庭宽带 IP 持续向海外传输大量加密数据——这种时间和流量的组合不符合正常用户的行为特征。 - **流量模式与声称的协议不匹配**：你的连接 SNI 指向 apple.com，但流量特征表现为长时间的流媒体传输（如持续稳定的高码率数据流），而不是正常网页浏览的短突发模式。SNI 与流量行为之间的矛盾是一个可疑信号。 - **单一 IP 的高带宽利用率**：一个家庭宽带 IP 长期占满其上行带宽，且所有高带宽流量都指向同一个海外 IP。这种模式在正常上网行为中极为罕见。 **防范措施**： - **多节点轮换**：将流量分散到多个海外 IP 上，避免长期连接单一节点。大多数代理客户端（如 Clash、Sing-box）都支持负载均衡或自动选择功能，可以在多个节点之间自动切换。 - **避免 24/7 全天候高带宽使用**：如果你需要长时间使用代理（如远程办公），尽量使用分流规则将国内流量直连，只代理必要的跨境流量。这样你的整体流量模式更接近正常用户。 - **使用中转线路**：中转线路通过国内的中转服务器将流量转发到海外节点。从 GFW 的视角看，它观察到的是中转服务器到海外的连接，而非你的家庭 IP 直连海外。中转服务器通常是数据中心 IP，其上有大量合法业务流量混杂，你的代理流量更容易被"淹没"在正常流量中。 --- ## 触发条件四：主动探测失败 GFW 不仅被动地监听流量——它还会主动出击。当被动检测系统将某个 IP 或端口标记为可疑后，GFW 会从中国境内的多个 IP 地址主动向该服务器发起连接，尝试验证其是否运行着代理服务。 **主动探测的工作方式**： - **重放攻击**：GFW 捕获用户与服务器之间的真实握手数据包，稍后从不同的 IP 重放这些数据包。如果服务器接受了重放的握手并建立连接，就可以确认其运行着代理服务。旧版 Shadowsocks 对重放攻击几乎没有防御能力，因此在主动探测面前非常脆弱。 - **协议嗅探**：GFW 以不同的协议格式尝试与服务器握手，例如发送疑似 Shadowsocks、VMess 等协议的探测包，观察服务器的响应。代理服务和正常 Web 服务器对这些非标准请求的响应行为存在差异。 - **行为差异检测**：旧版 Shadowsocks 的一个致命问题是——对合法客户端连接和非法探测连接的响应行为不同。例如，合法连接被正常处理，非法连接被静默断开。这种差异性行为本身就是一个识别特征。GFW 通过发送大量合法和非法请求并对比服务器的响应差异，可以高概率判断服务器是否运行代理。 **防范措施**： - **Reality 协议**：当探测者连接 Reality 服务端时，如果无法提供正确的认证信息（短 ID 和私钥），服务端会将连接无缝代理到预设的真实目标网站。探测者看到的是一个完全正常的网站，无法判断背后是否运行代理。这种"无差别响应"的设计哲学是 Reality 抗主动探测的核心优势。 - **SS-2022 的重放保护**：Shadowsocks 2022 引入了基于时间戳的会话过滤机制。每个握手包都包含时间窗口校验，过期的或重放的握手包会被自动拒绝，且拒绝行为与普通连接超时无法区分。 --- ## 触发条件五：IP 信誉 并非所有 IP 地址在 GFW 眼中都是平等的。IP 的历史记录和关联信息构成了它的"信誉评分"，信誉越低的 IP 受到的审查越严格。 **影响 IP 信誉的因素**： - **历史使用记录**：如果一个 IP 地址曾经被用于运行代理服务并被封锁过，即使后来换了用户和用途，GFW 可能仍然对这个 IP 保持更高的监控等级。很多便宜的 VPS 提供商会将被释放的 IP 重新分配给新用户，而这些 IP 可能已经带着"前科"。 - **VPN 提供商的 IP 段**：知名 VPN 服务（如 NordVPN、ExpressVPN、Surfshark 等）使用的 IP 段已经被 GFW 广泛收录。即使这些 VPN 频繁更换服务器 IP，GFW 也会通过 AS 号和 IP 段归属关系追踪它们的新 IP。 - **共享主机的连坐效应**：如果你使用的 VPS 所在的 IP 段中有大量其他用户也在运行代理，整个 IP 段可能会被 GFW 标记为高风险。即使你的节点配置完美，你也可能因为"邻居"的行为而被牵连。这在某些以代理用户为主要客户群的廉价 VPS 提供商中特别常见。 - **数据中心 IP 的天然劣势**：GFW 知道哪些 IP 段属于知名数据中心（如 AWS、GCP、Azure、DigitalOcean、Vultr、Bandwagon 等）。这些 IP 段中运行代理的比例远高于普通住宅 IP，因此它们受到的监控力度也更大。 **防范措施**： - 选择 IP 历史相对干净的 VPS 提供商。可以使用 IP 查询工具检查新获取的 IP 是否在各种黑名单中。 - 避免使用代理用户过度集中的提供商。如果一个提供商在中文技术论坛上因"适合做代理"而广为人知，那么它的 IP 段很可能已经被重点监控。 - 如果条件允许，选择非数据中心 IP（如住宅 IP 或商业宽带 IP），这些 IP 的基础信誉通常更好。 --- ## 触发条件六：端口特征 代理服务使用的端口号也是 GFW 分析的维度之一。虽然端口本身不足以直接触发封锁，但不当的端口选择可能增加被标记的风险。 **端口相关的风险因素**： - **非标准高端口**：如果你的代理运行在如 23456、54321 这样的非标准高端口上，而该端口上的流量全部是加密连接，这种模式不符合正常 Web 服务的特征。正常的 HTTPS 网站运行在 443 端口，正常的 HTTP 运行在 80 端口，其他端口上的大量加密流量更容易被标记为异常。 - **同一 IP 多端口多服务**：在一个 IP 上同时运行多个不同端口的代理服务（如 443 跑 VLESS、8443 跑 Trojan、9000 跑 Shadowsocks），从外部看就像一台"代理服务器农场"。这种多端口多协议的模式几乎可以确认该服务器的主要用途是代理。 **防范措施**： - **使用 443 端口**：443 是标准 HTTPS 端口。你的代理流量混在全球海量的正常 HTTPS 流量中，从端口层面来看完全正常。 - **一个 IP 只运行一个代理协议**：避免在同一 IP 上叠加多种代理服务。如果需要多种协议，使用不同的服务器 IP。 --- ## 触发条件七：DNS 关联 DNS 查询行为可以间接暴露你的代理使用。虽然 DNS 关联不会直接导致节点被封，但它可能将你标记为"翻墙用户"，从而使你的 IP 受到更严格的监控。 **DNS 泄露的风险**： - **明文 DNS 查询暴露访问目标**：如果你在连接代理之前（或在代理之外）通过未加密的 DNS 查询解析了被墙域名（如 google.com、youtube.com），你的 ISP（运营商）和 GFW 都能看到这些查询记录。这些记录表明你在尝试访问被封锁的网站，你的 IP 会被标记为"可能的翻墙用户"。 - **DNS 查询模式分析**：即使单次 DNS 查询不足以触发什么，长期的 DNS 查询日志可以揭示你的上网模式。频繁解析大量被封锁域名的 IP 显然更可能在使用代理。 - **ISP 级别的 DNS 监控**：中国的主要运营商对用户的 DNS 查询有全面的日志记录能力。这些日志可能与 GFW 的流量分析系统联动——如果一个 IP 既有大量被封锁域名的 DNS 查询记录，又有指向海外 IP 的持续加密连接，两者关联后的判定准确度会大幅提高。 **防范措施**： - **使用加密 DNS**：配置 DoH（DNS over HTTPS）或 DoT（DNS over TLS）来加密 DNS 查询，防止 ISP 和 GFW 窥探你的 DNS 请求内容。 - **使用 Fake-IP 模式**：在支持 Fake-IP 的代理客户端（如 Clash、Sing-box）中启用该模式。Fake-IP 会在本地为被代理的域名分配虚拟 IP，真正的 DNS 解析在远端服务器上完成，本地不产生任何真实的 DNS 查询。这从根本上消除了 DNS 泄露的可能性。 - **确保代理客户端接管了所有 DNS 查询**：检查你的代理配置，确保没有 DNS 请求在代理隧道之外泄露。特别注意系统级 DNS 配置和浏览器的安全 DNS 设置可能造成的旁路。 --- ## 敏感时期的特殊情况 GFW 的封锁力度并非一成不变——它随政治周期明显波动。理解这种周期性规律，有助于提前做好准备。 **典型的敏感时期**： - **全国两会（每年 3 月）**：人大和政协会议期间，网络管控力度通常会显著提升。 - **国庆节前后（每年 10 月）**：特别是逢十周年大庆，封锁力度更强。 - **特定历史纪念日**：某些日期前后 GFW 会提前加强检测。 - **突发公共事件**：重大社会事件发生时，GFW 可能临时加强封锁以控制信息传播。 **敏感时期的变化**： - **检测阈值大幅降低**：平时不会触发封锁的轻微异常（如偶尔的 TLS 指纹不匹配）在敏感时期可能直接导致 IP 被封。 - **主动探测频率增加**：GFW 的主动探测系统在敏感时期会更频繁地扫描可疑 IP。 - **封锁执行更快**：从检测到异常到执行封锁的时间窗口显著缩短。 - **预防性封锁**：GFW 可能根据已有的 IP 信誉数据库，预先封锁一批"高概率代理服务器"的 IP，甚至在这些服务器表现出任何异常之前。 **应对策略**： - 优质的机场（代理服务提供商）会为敏感时期提前准备备用 IP 和快速轮换机制。 - 如果你自建节点，建议在敏感时期前准备至少一个备用服务器 IP。 - 在敏感时期适当降低代理使用强度，减少触发行为分析检测的概率。 - 即使配置完美的节点在敏感时期也可能被临时封锁。这通常不是永久性的——大多数因敏感时期而被封锁的 IP 会在事件结束后数天到数周内自动恢复。 --- ## 封锁类型 GFW 的封锁措施并非只有一种。了解不同的封锁类型，有助于你准确判断情况并采取正确的应对措施。 ### IP 封锁 最严厉的封锁方式。整个 IP 地址在所有端口上都被阻断，该服务器上的任何服务都无法从中国大陆访问。 - 表现为：ping 不通、TCP 连接超时、traceroute 在国际出口处中断。 - 通常发生在 GFW 高度确认该 IP 运行代理服务之后。 - 恢复可能性低。唯一可靠的解决方案是更换服务器 IP。 - 部分 VPS 提供商允许免费更换 IP，但次数通常有限。 ### 端口封锁 相对温和的封锁方式。GFW 只阻断特定 IP 上的特定端口，服务器在其他端口上仍然可达。 - 表现为：代理连接失败，但可以通过其他端口 SSH 登录服务器。 - 通常发生在 GFW 识别到某个端口上的代理流量但尚未确认整个 IP 都用于代理时。 - 应对方式：将代理服务迁移到另一个端口。但要注意，频繁切换端口本身也可能被视为可疑行为。 ### 临时封锁 vs 永久封锁 - **临时封锁**：持续数小时到数天，常见于敏感时期的大规模封锁。GFW 在特殊时段临时降低封锁阈值，事后恢复常规水平，被封锁的 IP 随之自动解除。没有明确的解封时间表——可能几小时就恢复，也可能持续数周。 - **永久封锁**：IP 被加入长期黑名单，不会自动恢复。通常发生在 IP 被反复确认用于代理服务之后。唯一的解决方案是更换 IP。 - **无法预判类型**：当你的 IP 被封时，无法提前知道这是临时还是永久封锁。一般建议等待 24-48 小时观察，如果仍未恢复则考虑更换 IP。 ### 精准封锁 vs 范围封锁 - **精准封锁**：只封锁特定的单个 IP 地址。这是最常见的封锁方式，影响范围最小。 - **范围封锁（子网封锁）**：封锁整个 IP 子网段（如 /24 段，即同一 C 段的 256 个 IP）。这种封锁方式影响范围更大，会殃及同一子网中与代理无关的 IP 地址。范围封锁通常发生在 GFW 判定某个 IP 段被代理用户大量使用时——与其逐个封锁，不如直接封锁整个段。这也是为什么选择代理用户过度集中的 VPS 提供商风险更高的原因之一。 --- ## 如何减少被封风险 综合以上所有触发条件，以下是降低节点被封概率的实践建议： **1. 使用 VLESS+Reality 并正确配置** 这是当前抗检测能力最强的协议组合。Reality 同时解决了 DPI 识别、TLS 指纹暴露和主动探测三个核心问题。配置时需要注意选择合适的目标网站（dest），确保其支持 TLS 1.3 和 HTTP/2。 **2. 使用 443 端口** 443 是全球 HTTPS 流量的标准端口。你的代理流量在端口层面与海量正常 HTTPS 流量无法区分。使用非标准端口是不必要的风险。 **3. 选择信誉良好的服务器提供商** 避免使用以代理用户为主要客户群的提供商——如果一个提供商在中文社区以"适合翻墙"闻名，它的 IP 段大概率已被重点监控。选择面向正常业务的主流提供商（如部分非热门区域的 AWS、GCP 节点），虽然价格可能略高，但 IP 信誉更好。 **4. 不要裸跑协议** 任何代理协议都不应在没有适当伪装的情况下直接暴露在公网上。裸 VMess、旧版 Shadowsocks、未加密的 SOCKS5 等在当前环境下几乎等于直接告诉 GFW"请封我"。 **5. 控制单节点的带宽和使用时长** 避免长时间在单一节点上保持极高的带宽利用率。这种模式在流量行为分析中是强异常信号。如果需要高带宽使用（如下载大文件、长时间观看高清视频），尽量使用多节点轮换或中转线路来分散流量。 **6. 使用中转/接入线路** 中转线路在你的设备和海外节点之间增加一个国内中转节点。从 GFW 的角度看，它只能观察到中转节点与海外节点之间的连接，而无法直接关联到你的家庭 IP。此外，中转节点通常是数据中心 IP，其上混杂着大量其他业务流量，代理流量更容易被"稀释"。 **7. 保持备用节点** 永远不要只依赖单一节点。准备至少一到两个备用节点（最好位于不同 IP 段、不同提供商、甚至不同国家），在主节点被封时可以立即切换。对于机场用户来说，这通常不是问题，因为机场本身会提供多个节点；对于自建用户，需要自己维护备用节点。 **8. 敏感时期降低使用强度** 在已知的敏感时期，适当降低代理使用的频率和带宽。如果不是必须，可以暂时减少不必要的跨境流量。这不是因为某个特定的操作会触发封锁，而是敏感时期的检测阈值整体偏低，任何轻微的异常都可能被放大。 --- ## 常见问题 ### Q: 被封了能解封吗？ 没有任何"申请解封"的途径。GFW 的封锁是由自动系统执行的，不存在人工审核或申诉渠道。唯一可靠的解决方案是更换 IP 地址。部分临时性封锁（特别是敏感时期的大范围封锁）会在数天到数周后自动解除。如果你的 IP 被封超过两周仍未恢复，基本可以判断为永久封锁，应当更换 IP。 ### Q: 自建节点和机场哪个更容易被封？ 各有优劣，不能简单地说哪个更好。**自建节点**的优势在于只有你一个人使用，流量特征不明显，不存在因其他用户行为而被连坐的风险。劣势在于一旦被封，你需要自己处理——更换 IP、重新配置、重新部署，这需要技术能力和时间。**机场**的优势在于拥有大量节点和快速的 IP 轮换能力，单个节点被封不影响整体可用性。劣势在于共享 IP 的连坐风险——如果其他用户的不当行为（如大量 BT 下载、大流量视频）触发了 GFW 的检测，你的节点也会受到影响。 ### Q: 用了 Reality 就不会被封吗？ Reality 极大降低了在协议层面被检测的风险——它解决了 DPI 识别、TLS 指纹异常和主动探测这三个最主要的技术层面触发条件。但它**无法解决**流量行为分析和 IP 信誉这两个维度的问题。如果你在一个已经被标记的 IP 上部署 Reality，或者你的使用模式表现出明显的异常特征（如长期高带宽连接单一海外 IP），仍然可能触发封锁。**没有任何方案能提供百分之百的抗封锁保证**——这是一场持续的攻防博弈，而非一劳永逸的技术方案。 ### Q: 为什么别人能用我不能用？ 这种情况有多种可能的原因： - **ISP 差异**：不同运营商（中国电信、中国联通、中国移动）的检测力度和策略存在差异。某些运营商在某些地区的审查可能更严格。 - **地区差异**：不同省份和城市的 GFW 执行力度不同。一线城市和敏感地区的检测通常更严格。 - **精准封锁**：你的 IP 或端口被精准封锁，而不是该节点的所有用户都被封。不同用户经过的骨干网路径不同，可能只有经过特定路由节点的连接被阻断。 - **DNS 差异**：你的 DNS 配置可能存在泄露，而其他用户的配置没有这个问题。 - **时间差异**：GFW 的封锁不是瞬间全国生效的，可能存在地区性的时间差。你可能正好在封锁生效的窗口期，而其他用户还未受影响。