很多人翻墙就像盲人摸象，复制别人给的配置，一失效就抓瞎。这个视频不是为了给你提供免费订阅，而是为了把抽象的技术对抗还原成底层的运行逻辑。只有弄懂了 GFW 是如何”封”的，你才能真正明白如何”绕”过它，并避免在未知的免费节点上遭受金融和隐私损失。

视频教程

一、前言：为什么需要这篇教程

本节将覆盖以下三种情况：

1. 认知模式为 互联网设计的原始初衷
2. 认知模式为 墙内用户的盲人摸象
3. 认知模式为 探究底层原理的必要性

认知模式：互联网设计的原始初衷

1. 互联网在设计之初，核心理念是端到端的开放互联。
2. 早期工程师们构建底层协议（假设世界上任意两台计算机都能自由、直接地交换数据）。
3. 我们认为信息的流动应当是没有人为物理阻隔的。

认知模式：墙内用户的盲人摸象

1. GFW（防火长城）的出现强行阻断了内外两端的直接连接。
2. 墙内用户无法直接访问海外节点，于是只能依靠口耳相传、盲目复制别人给的代理配置。
3. 很显然，当这些黑盒配置失效或者节点被封锁时，用户往往无从下手，只能被动等待。

认知模式：探究底层原理的必要性

1. 我们这篇教程不再仅仅提供现成的订阅链接。
2. 我们把抽象的技术对抗还原成具体的底层运行逻辑。
3. 用户在掌握了核心原理之后，于是能够自主排查网络故障，避开劣质代理节点带来的安全隐患。

二、正常的网络请求流程

在讲解防火墙怎么封之前，我们先了解一下正常的网络请求流程：

1. 浏览器想要访问目标网站时，必须先知道目标网站真实的 IP 地址。
2. 浏览器向 DNS 服务器发送查询请求。
3. DNS 服务器返回该网站真实的 IP 地址。
4. 浏览器向该真实 IP 地址发起数据连接。

三、GFW 的工作原理：墙是怎么”封”的

本节将覆盖以下六种情况：

1. 墙的工作模式为 DNS 污染
2. 墙的工作模式为 IP 封锁
3. 墙的工作模式为 关键词过滤
4. 墙的工作模式为 SNI 检测
5. 墙的工作模式为 深度包检测
6. 墙的工作模式为 速率限制与干扰

DNS 污染

1. 浏览器向公共 DNS 服务器发起对于被墙域名的查询请求。
2. 流量在跨越跨境网关时，GFW 的旁路设备嗅探到了这个明文的 DNS 查询包。
3. GFW 抢在真实的 DNS 服务器回应之前，伪造了一个包含错误 IP 的响应包发送给浏览器。
4. 浏览器：你对应的真实 IP 是多少？ GFW（伪装成DNS）：是 127.0.0.1。 浏览器：好的，我立刻向 127.0.0.1 发起连接。
5. 很显然，浏览器连接到了完全错误的地址，于是目标网页无法打开。

IP 封锁

1. 浏览器通过某种安全手段获取到了被墙网站的真实海外 IP 地址。
2. 浏览器直接向这个真实的海外 IP 发起 TCP 连接请求。
3. 数据包抵达 GFW 路由器时，GFW 检查了数据包的目标 IP 地址。
4. GFW 发现这个目标 IP 存在于它的黑名单 IP 段中，于是直接在硬件层面上将该数据包丢弃。
5. 浏览器：你好目标网站，我要建立数据连接。 GFW：……（不予理睬，直接把拦截到的包扔掉） 浏览器：……（等待超时后报错失败）

关键词过滤

1. 浏览器与海外普通服务器建立了普通的 HTTP（明文）连接。
2. 浏览器向海外服务器发送 HTTP GET 请求包，请求的明文内容中包含了敏感关键词。
3. GFW 在中间拦截并检查这个数据包，在明文的正文中发现了黑名单关键词。
4. GFW 伪造 TCP Reset 包，分别发送给浏览器和海外服务器强制切断连接。
5. GFW（向浏览器发包）：海外服务器说它不想理你了，连接重置。 GFW（向海外服务器发包）：浏览器说它不想理你了，连接重置。 浏览器：……（收到伪造的阻断指令，连接强行断开）
6. 随着如今 HTTPS 的全面普及，流量内容被全程加密，于是这招的效果已经大幅减弱。

SNI 检测

1. 浏览器与目标网站建立了 HTTPS（加密）连接的握手过程。
2. 浏览器向目标网站发送 TLS Client Hello 握手包，请求中包含了明文的 SNI 扩展字段。
3. GFW 在中间拦截并检查这个握手数据包，在明文的 SNI 扩展字段中发现了黑名单域名。
4. GFW 伪造 TCP Reset 包，分别发送给浏览器和目标网站强制切断连接。
5. GFW（向浏览器发包）：目标网站说它不想理你了，连接重置。 GFW（向目标网站发包）：浏览器说它不想理你了，连接重置。 浏览器：……（收到伪造的阻断指令，连接强行断开）
6. 很明显，只要建立连接时的 SNI 域名验证字段仍是明文，GFW 就能精准切断访问。

深度包检测（DPI）

1. 代理客户端与海外代理服务器建立连接，双方开始传输经过加密的数据。
2. GFW 在中间拦截到了这些数据包。但是，GFW 此时无法解密内容，没法直接比对敏感词，怎么办？
3. GFW 放弃读取明文内容，它转而分析这股流量的统计特征（注意，这包括数据包的大小、发送的时间间隔、握手阶段的固定字节序列等外部特征）。
4. GFW 发现这股流量的指纹高度符合早期某款代理协议（如 Shadowsocks）的固有通信特征。
5. GFW 主动伪装成普通客户端，向该海外代理服务器发起探测连接。
6. GFW：你好，按照 Shadowsocks 协议的格式，我们对一下暗号？ 代理服务器：暗号正确，连接成功。 GFW：……（记录确凿证据，立刻向主系统下达封锁该 IP 的指令）
7. 代理服务器给出了符合翻墙协议规范的响应，于是 GFW 确定它就是一个翻墙服务器并进行了精准封锁。

速率限制与干扰

1. 浏览器与某个尚未被封锁的海外服务器建立连接，持续传输数据。
2. GFW 的流量监控引擎对这股数据流进行了实时分析。但是，GFW 此时无法 100% 确认这到底是不是翻墙流量，直接封锁可能会误伤正常跨国业务，怎么办？
3. GFW 采取了不完全封锁的干扰策略，它不直接切断连接，而是故意高频丢弃数据包或强行限制带宽速率。
4. 客户端：你好服务器，请把下半段数据发给我。 GFW：……（故意截留这部分数据包） 客户端：由于没收到数据，请再发一次。
5. 浏览器经历了极度严重的丢包重传，于是用户体验彻底恶化，网页卡顿直至无法加载。

四、翻墙的核心思路：如何绕过墙

本节将覆盖以下四种情况：

1. 绕过模式为 基础代理
2. 绕过模式为 流量混淆
3. 绕过模式为 协议加密
4. 绕过模式为 节点分散

GFW 封锁的核心逻辑

1. GFW 作为网络中的审查节点，它必须明确知道两个信息中的至少一个，才能进行有效阻断。
2. 它要么需要知道”你在和谁通信”（目标 IP 或域名），要么需要知道”你在传输什么内容”（敏感明文或特征指纹）。

基础代理

1. 本地代理客户端与位于墙外的代理服务器建立连接（假设最终目标网站是 Google）。
2. 浏览器不再直接请求目标网站，而是把所有请求发给本地的代理客户端（注意，这里以流行的 mihomo 客户端为例）。
3. mihomo 读取到了它的本地规则配置文件：

1
2
3
4
5

proxies:
- name: "Proxy-A"
  type: ss # 代理协议类型，采用 shadowsocks 协议
  server: 198.51.100.1 # 墙外真实代理服务器的 IP 地址
  port: 443 # 墙外代理服务器的监听端口

4. mihomo 看到了这个配置，于是直接向位于 198.51.100.1 的 443 端口发起了协议连接。
5. mihomo 将浏览器发来的原始请求打包封装，全部定向发送给该墙外服务器。
6. mihomo：麻烦帮我获取一下 Google 的首页数据。 代理服务器：收到，我这就去向 Google 发起请求，拿到了再返回给你。 mihomo：好的，我在这里等待结果。
7. 代理服务器将获取到的 Google 数据传回给 mihomo，mihomo 解包后转交给浏览器。
8. 很显然，GFW 只能看到 mihomo 一直在和 198.51.100.1 通信，它完全不知道我们实际上在访问 Google。

流量混淆

1. 代理客户端与墙外代理服务器建立连接，准备传输代理数据。但是，GFW 的深度包检测引擎会通过统计特征识别出代理协议，怎么办？
2. mihomo 为了防止 GFW 识别出底层协议的特征，开始对即将发出的流量进行深度伪装。
3. mihomo 在真实的代理数据包外部，套上了一层完美模仿正常 HTTP 或 TLS 网页访问的头信息。
4. mihomo：你好目标服务器，我要看伪装站点的普通图文网页。 GFW：……（引擎自动检查了一下，判定这是一次完全合规的普通网页访问） 代理服务器：好的，这是你的普通网页数据。（实际上内部包裹着真正的加密代理数据）
5. GFW 被这层毫无破绽的表面伪装数据欺骗，于是直接放行了这股流量。

协议加密

1. 本地代理客户端与墙外代理服务器建立连接，并在握手阶段协商好极高强度的加密密钥。
2. mihomo 读取到了它的密码学配置文件：

1
2
3
4
5

proxies:
- name: "Proxy-A"
  type: ss # 代理协议类型
  server: 198.51.100.1 # 墙外服务器 IP
  cipher: chacha20-ietf-poly1305 # 双方约定的高强度加密算法

3. mihomo 看到了这个配置，于是使用 chacha20-ietf-poly1305 算法对所有包含目标域名和具体内容的数据进行加密。
4. mihomo 将彻底加密后的乱码数据包发往代理服务器。
5. GFW 捕获到了这些数据包，但由于没有密钥，它绝对无法读取其中的真实通信内容。

但是：如果加密后的数据包表现出完全无规律、全随机的特征（极高的信息熵），反而会因为”过于神秘”而引起 GFW 的高度怀疑。GFW 虽然无法解密内容，但它直接根据这种”未知的全加密特征”进行随机丢包。很明显，纯粹的加密并不等于完全隐蔽，于是现代代理协议必须将高强度加密与流量混淆结合使用。

节点分散

1. 本地代理客户端试图连接位于墙外的真实代理服务器。
2. 真实代理服务器的入口 IP 往往只有固定的一个，一旦暴露被 GFW 盯上就会彻底失联。
3. mihomo 修改了路由策略，将流量指向了全球分布的商业 CDN（内容分发网络）服务商节点。
4. mihomo：我要连接全球公用的 CDN 节点 IP 并请求数据。 CDN 节点：收到请求，我帮你把流量转发给隐藏在我背后的真实代理服务器。 真实代理服务器：处理完毕，数据沿 CDN 通道原路返回。
5. GFW 只看到用户在与全球知名 CDN 服务商的庞大 IP 池进行通信。GFW 绝对无法直接封锁该 CDN 厂商的所有 IP（因为这会导致大量无辜的正常跨国商业运作瘫痪），于是代理流量得以在 CDN 节点的掩护下长期存活。很显然，真实代理服务器的 IP 被完美隐藏了起来。

五、主流协议演化史：一场猫鼠游戏

本节将覆盖以下六种情况：

1. 协议阶段为 早期 VPN
2. 协议阶段为 过渡期乱码加密
3. 协议阶段为 混淆期伪装
4. 协议阶段为 现代模块化
5. 协议阶段为 主流真实 TLS
6. 协议阶段为 最新 UDP 协议

什么是协议特征

协议特征就如同两个人在通信时使用的特定语言语法和加密格式。哪怕通信内容是完全加密的，审查设备只要识别出这种特定的通信格式，就能断定这是一条代理通道。翻墙协议的演进史，就是一部抹除自身特征、对抗深度包检测（DPI）的历史。

早期 VPN

1. 早期网民直接使用针对企业办公设计的 PPTP 或 OpenVPN 协议与海外服务器建立连接。
2. 本地设备向海外服务器发送具有明显企业 VPN 标识的明文握手包。
3. 客户端：你好，我要建立一条标准的 PPTP 隧道。 服务器：收到，隧道建立成功。 客户端：好的，开始传输加密数据。
4. GFW 监听到了这股带有极强 VPN 固有特征的流量。
5. 很显然，大量普通家用宽带高频向海外发起企业级专线连接是不合常理的，于是 GFW 轻易识别出特征并直接切断了连接。

过渡期乱码加密

1. 开发者设计了 Shadowsocks 等轻量级协议与海外服务器建立连接。
2. 客户端抛弃了固定的明文握手，而是将所有传输数据彻底加密成毫无规律的乱码。
3. GFW 检查数据包时，发现这股流量失去了所有已知的协议特征，呈现出极高的信息熵。

但是：完全没有任何特征的全加密乱码，本身不就是一种最大的特征吗？

4. GFW 提取了这种”未知高熵乱码”特征，并主动伪装成普通客户端向海外服务器发起试探。
5. GFW：你好，按照 Shadowsocks 的规范，我们对一下握手暗号？ 海外服务器：暗号正确，这是你要的数据。 GFW：……（记录证据，立刻将该海外服务器的 IP 封锁）
6. 海外服务器没有针对主动探测进行防备，于是节点成批失效。

混淆期伪装

1. 开发者在原本乱码加密的数据包外部加入了一层混淆插件（Obfs）。
2. 客户端在向海外服务器发送代理数据前，为其套上了一层模仿普通 HTTP 网页请求的外壳。
3. 客户端：你好，我要看普通的 HTTP 明文网页。（实际上内部包裹着高熵乱码的代理数据） 服务器：收到，这是你要的普通网页数据。（实际上内部是代理服务器取回的真实数据） 客户端：好的，继续通信。
4. GFW 检查了这股带有 HTTP 伪装外壳的流量。
5. GFW 的深度包检测引擎仔细比对了这层伪装外壳与真实 HTTP 协议之间的微小结构差异。
6. 很明显，早期的模拟伪装并不完美（注意，这会暴露出逻辑漏洞），于是 GFW 识破了伪装并再次进行阻断。

现代模块化

1. 开发者引入了 V2Ray 等模块化内核，客户端与海外服务器开始建立基于标准网络传输协议的连接。
2. mihomo 读取到了它的出站代理配置：

1
2
3
4
5

proxies:
- name: "Proxy-V"
  type: vmess # 代理协议类型
  server: 198.51.100.2 # 代理服务器 IP
  network: ws # 将底层流量伪装成标准的 WebSocket 连接

3. mihomo 看到了这个配置，于是将本地所有的代理数据流完全塞进了真正的 WebSocket 协议通道中。
4. 客户端：你好服务器，我要建立一个符合 W3C 标准的 WebSocket 长连接。 GFW：……（比对了标准协议规范，发现格式 100% 一致，予以放行） 服务器：同意建立 WebSocket 连接。
5. 客户端完全复用了现成的互联网标准协议来承载代理数据，于是 GFW 很难从外部数据包结构中找出破绽。

主流真实 TLS

1. 客户端抛弃了”模拟伪装”的思路，改为与海外服务器直接建立真实的 TLS（HTTPS）加密连接。
2. mihomo 读取到了它的安全层配置文件：

1
2
3
4
5
6

proxies:
- name: "Proxy-X"
  type: vless # 主流轻量代理协议
  server: 198.51.100.3
  tls: true # 开启真实的 TLS 加密
  servername: www.example.com # 伪装访问的真实合法域名

3. mihomo 看到了这个配置，于是直接向服务器发起真实的 HTTPS 握手，并使用合法的数字证书进行验证。
4. 客户端：你好，我要与 www.example.com 建立 TLS 1.3 加密连接。 服务器：收到，这是由权威机构颁发的真实数字证书。 客户端：证书验证通过，开始传输全加密内容。
5. 面对这种完全真实的 HTTPS 流量，GFW 根本无法区分这究竟是用户在访问真实的海外网站，还是在通过代理通道翻墙。
6. 真实流量彻底取代了人工模拟伪装，于是代理通道的生存概率得到了跨越式的提升。

最新 UDP 协议

1. 客户端放弃了容易受到干扰的传统 TCP 协议，转而使用基于 UDP 的 QUIC 协议与海外服务器建立连接。
2. mihomo 读取到了针对 Hysteria2 协议的配置：

1
2
3
4
5

proxies:
- name: "Proxy-H"
  type: hysteria2 # 基于 UDP 的新一代协议
  server: 198.51.100.4
  password: my_secret_auth_password # 独有的密码认证机制

3. mihomo 看到了这个配置，于是直接通过无连接状态的 UDP 通道向服务器发送包含密码认证的高速数据包。
4. 客户端：你好，这是带有认证密码的 UDP 暴力数据包。 GFW：……（面对全新的 UDP 数据流特征，现有的 TCP 拥塞控制和干扰模型无法直接生效） 服务器：密码验证正确，建立高速传输通道。
5. 基于 UDP 的新协议无视了跨国 TCP 链路的高延迟与丢包干扰，于是用户获得了跑满物理带宽的极高访问速度。

六、节点与订阅：翻墙工具的结构

本节将覆盖以下三种情况：

1. 工具结构为 基础节点
2. 工具结构为 机场订阅
3. 工具结构为 客户端解析

什么是代理链路

代理链路就是从你手中的本地设备，经过墙外的跳板服务器，最终抵达目标网站的完整数据转发路径。这条路径的稳定运行需要服务端环境与客户端配置的绝对对称。

基础节点

1. 个人用户租用了一台位于海外的云服务器主机。
2. 用户在这台服务器上安装了代理服务端程序，并配置好了特定的端口与加密密钥。
3. 这台拥有固定海外 IP 且配置完毕的服务器，连同它的连接参数，共同构成了一个能够独立运作的基础”节点”。
4. 用户的本地客户端向这个唯一节点发起连接请求。
5. 客户端：你好节点，请帮我把这些数据转发给目标网站。 节点（海外服务器）：收到，正在执行转发操作。 客户端：好的，我等待回传。
6. 很明显，这种单点结构的可用性完全依赖于这台海外服务器的存活状态，一旦该 IP 被 GFW 封锁，代理链路就会彻底中断。

机场订阅

1. 商业服务商批量租用了分布在全球各个国家的大量海外服务器线路。
2. 服务商将这些支持不同协议的数十个节点进行统一编号和参数打包。

但是：普通新手用户不懂技术，怎么可能手动把这几十个节点的复杂参数准确无误地填进软件里？

3. 服务商在自己的官方服务器上生成了一串包含所有节点完整配置的动态链接（即订阅链接）。
4. 用户的客户端软件向服务商的域名发起 HTTP 拉取请求。
5. 客户端：你好，我是付费用户，请下发最新的可用节点列表。 服务商服务器：身份验证通过，这是包含 100 条节点参数的配置文件。 客户端：接收完毕，保存在本地。
6. 这种批量出售节点服务，且能像现实中飞机落地一样提供大量国家出口线路的商业模式，于是被网民形象地称作了”机场”。

客户端解析

1. 用户的本地代理内核（如 mihomo）接收到了上一节提到的订阅链接数据。
2. mihomo 读取到了其内部的订阅更新配置模块：

1
2
3
4
5

proxy-providers:
  Airport-Subscription:
    type: http # 从网络上获取节点
    url: "https://example.com/api/v1/client/subscribe" # 服务商提供的专属订阅地址
    interval: 86400 # 设定每隔 24 小时自动向服务器请求一次最新数据

3. mihomo 看到了这个配置，于是按照设定的时间间隔自动访问链接，并将拉取到的加密乱码解码为标准的本地节点规则。
4. mihomo 随后向解析出的所有节点批量发送网络测速包。
5. mihomo（向所有节点广播）：请各自报告当前的通信延迟。 节点A（日本）：我的延迟是 45ms。 节点B（美国）：我的延迟是 180ms。 mihomo：很好，我自动将系统的默认路由指向延迟最低的日本节点A。
6. 复杂的底层参数被客户端完全隐藏并实现了自动化统筹，于是新手用户只需要在界面上点击更新，就能获得流畅的翻墙体验。

七、安全与风险意识

本节将覆盖以下五种情况：

1. 风险来源为 法律灰色地带
2. 风险来源为 服务商信任危机
3. 风险来源为 DNS 泄漏
4. 风险来源为 WebRTC 泄漏
5. 风险来源为 行为轨迹关联

什么是隐私泄露

隐私泄露在网络对抗的语境下，指的是原本应该被完全加密隐藏的数据，因为外围系统的配置缺陷，被暴露给了不应该看到的第三方。防火墙拦截阻断只是网络层面的封锁，而隐私泄露直接威胁到物理层面的个人安全。

法律灰色地带

1. 普通网民在本地设备上运行代理客户端，建立起通往海外节点的加密隧道。
2. 宽带运营商的旁路审查设备全天候监控着所有用户的跨境出入口数据流。

既然内容已经被完全加密了，执法机关怎么知道用户存在违法违规行为？

3. 审查设备根本不去破解加密内容，它只记录本地 IP 访问的目标国别，以及持续稳定的大流量传输特征（注意，长时间的高带宽跨境 TCP/UDP 连接本身就是一种高度异常的标记）。
4. 审查设备：这个厦门的家用宽带 IP，每天向海外某个未知节点发送了几十 GB 的高熵加密数据。 执法机关：收到，提取该宽带账号绑定的实名登记信息。 审查设备：实名信息已回传，随时可以下发断网警告或进行进一步的溯源调查。
5. 很明显，个人偶尔查阅资料与大规模传播盈利的流量特征差异极大，于是执法机关通常会根据流量规模和行为动机进行分级判定。

服务商信任危机

1. 用户的代理客户端将所有的网络请求打包装发，毫无保留地交给了机场服务商的节点服务器。
2. 机场服务器作为中间人，负责解包并代为向真正的目标网站发起请求。

机场的运营者能不能暗中偷看我的密码和聊天记录？

3. 当用户通过代理访问未加密的 HTTP 网站时，由于缺乏端到端加密，机场服务器确实能截获所有的明文数据。
4. 客户端：你好节点，帮我请求这个普通的明文论坛。 机场服务器（暗中窃取）：拦截到了论坛账号和明文密码，先复制存进我的本地数据库。 机场服务器（对外转发）：正在帮你向论坛发起登录请求。
5. 当用户访问主流的 HTTPS 加密网站时，数据在浏览器端就已经完成了严密的密码学加密。
6. 客户端：你好节点，帮我把这包 HTTPS 加密乱码转交给银行的服务器。 机场服务器（尝试破解）：由于我没有这把私钥，完全解不开乱码，但我能看到你要访问的目标网址是银行。 机场服务器（对外转发）：原样把乱码丢给银行。
7. 既然通道提供者必定能掌握用户的访问目标（解析请求域名的能力），于是我们绝对不要在不知名或免费的节点上进行核心的金融与隐私业务。

DNS 泄漏

1. 本地代理客户端接收到了浏览器发出的，要求访问被墙网站的请求指令。
2. 此时由于配置疏漏，本地操作系统默认的 DNS 优先级错误地高于了代理软件的接管权限。
3. 操作系统没有通过加密代理通道，而是直接向国内的公共 DNS 服务器（如 114.114.114.114）发起了明文的域名查询。
4. 操作系统：你好 114 DNS，请问这个被墙网站的真实 IP 是多少？ 国内 DNS：……（发现被封锁域名，立刻返回错误 IP 进行污染，并顺手将这笔查询记录写入了审计日志） 操作系统：好的，我拿到了一个（实际上已经被污染的）IP。
5. 为了彻底堵住这个致命漏洞，mihomo 读取到了它的防泄漏配置文件：

1
2
3
4
5

dns:
  enable: true # 开启 mihomo 内置的 DNS 接管引擎
  enhanced-mode: fake-ip # 采用虚假 IP 模式拦截操作系统的底层查询
  nameserver:
    - https://1.1.1.1/dns-query # 强制通过加密代理向海外可信 DNS 发起 DoH 加密查询

6. mihomo 看到了这个配置，于是直接拦截操作系统的本地查询，并在内部构造一个虚假的内网 IP 欺骗系统，从而将真实的 DNS 查询强行塞进了通往海外的加密代理通道。
7. 很显然，国内 DNS 审查系统彻底失去了监听你浏览记录的机会。

WebRTC 泄漏

1. 浏览器为了实现网页音视频通话的极低延迟，在内核中内置了高权限的 WebRTC 协议功能。

哪怕开了全局系统代理，为什么某些网站还是能精准探测到我在国内？

2. 目标网站的页面中嵌有恶意的 WebRTC 探测代码脚本。
3. WebRTC 协议具备直接绕过系统网络栈，读取本地计算机所有物理网卡真实 IP（包括运营商分配的局域网与公网 IP）的底层硬件交互能力。
4. 目标网页：你好浏览器，我要发起 P2P 视频通信，请告诉我你底层的真实网络地址。 浏览器内核：收到，绕过代理机制，直接读取到底层物理网卡的真实 IP 是中国厦门。 目标网页：好的，我已经将这个真实地理 IP 偷偷传回了我的后台服务器日志中。
5. 代理软件只能接管标准的系统网络数据流，于是面对这种浏览器内核级别的直接越权硬件读取毫无防备（注意，我们必须在浏览器中安装防泄漏扩展或直接在 about:config 中禁用 WebRTC 才能根除此隐患）。

行为轨迹关联

1. 用户开启了完美无瑕的顶级代理通道，并在一个匿名的海外社交平台上尝试注册一个全新账号。
2. 用户在注册该账号时，为了图方便，直接在表单里绑定了自己国内常用的实名手机号或者常用的国内邮箱（如 QQ 邮箱）。
3. 海外社交平台后端接收到了注册请求，并触发了验证码发送机制。
4. 匿名平台：你好用户，我们要验证身份，已向你的国内邮箱发送了一封带有验证码的邮件。 国内邮箱服务器：拦截到一封来自海外敏感平台的注册确认信，立刻提取该邮箱绑定人的实名身份档案并建立关联标记。 用户：好的，我填入验证码，注册成功。
5. 很明显，底层的网络密码学隔离做得再完美，一旦在上层业务逻辑中混用了国内的实名身份标识，于是所有的匿名伪装都会瞬间崩塌。

实用链接

短信及语音接码平台

• hero-sms 接码平台

白嫖流量

• 500M试用：ipfly.net 优惠码 GXJDIAN，85 折优惠
• 200M试用：talordata 优惠码 GXJDIAN，9 折优惠

注意：链接需复制到浏览器中才能打开！

社区与社交媒体

1. 微信讨论群：加入微信群
2. 超过100T资料总站：doc.869hr.uk
3. Telegram群聊：t.me/tgmShareAI
4. 微信公众号：搜”AI前沿的短裤哥”
5. 视频文字博客：869hr.uk
6. 推特：@gxjdian
7. YouTube：@gxjdian

VPS 主机推荐

• Claude用的丽萨主机：lisahost.com
• 按流量VPS：lycheeip.com
• 一年10美元多年保底小鸡：zgovps.com
• 各种云主机，主打性价比：racknerd.com
• 美国VPS，一年70美金搞活动：cloudcone.com
• 一年8.5美金的美国家宽，稳定靠谱：webshare.io
• 家宽IP：ipfly.net
• 住宅VPS：voyracloud.com

Gmail、Telegram 等账号购买、礼品卡

• accboy7gxjdian.acceboy.com
• universalbus.cn
• gamsgo.com

Claude、OpenAI Codex 等充值

• bewild.ai 优惠码 GXJDIAN

eSIM 推荐

1. 三家eSIM对比：详细对比及开户链接
2. 9eSIM 打9折（优惠码：maq）：注册购买
3. ESTK 打9折（优惠码：GXJDIAN）：注册购买
4. XeSIM 打9折（推荐码：gxjdian）：注册购买

出海银行卡与支付

5. Wise 申请链接（推荐码：lizhiw12）：申请链接
6. N26 申请（推荐码：lizhiw02766c）：教程视频
7. Bybit 支付卡：申请链接 | 教程视频

专辑合集

• AI产品&技术相关专辑：YouTube 播放列表
• 出海收款、付款、银行卡、虚拟卡相关专辑：YouTube 播放列表
• 出海手机号相关专辑：YouTube 播放列表
• 出海网络搭建相关专辑：YouTube 播放列表
• 出海VPS相关专辑：YouTube 播放列表

关注我不迷路

如果你觉得这期视频对你有帮助，请务必：

• 点赞本视频
• 在评论区留下你的问题或成功注册的截图
• 订阅频道并打开小铃铛，获取最新硬核白嫖教程和科技前沿资讯！