返回
网络基础
作者: xxx | 发布时间: 2026-05-06 20:27:55 | ★ 0
# Cloudflare云原生架构与运维
====================================================================
Cloudflare 云原生架构与 Web 运维核心知识库
====================================================================
## 一、 域名与 DNS 解析原理
1. 角色分工：
- 域名注册商（如 Spaceship）：负责在互联网总账本中登记域名的所有权。
- DNS 托管商（如 Cloudflare）：负责接管域名的流量调度和解析记录管理。
2. 寻址与生效机制：
- 客户端访问域名时，会通过全球 DNS 系统查询目标服务器的 IP 地址。
- 修改 DNS 记录后，全球各地的运营商节点更新缓存通常需要 15 到 30 分钟的时间。
3. MX 记录 (Mail Exchanger)：
- 专用于电子邮件系统的解析记录，指示全网将发往该域名的邮件派送到指定的邮件服务器。
## 二、 Cloudflare Serverless (无服务) 架构体系
1. 平台定位：
- Cloudflare 是一家全球顶级的 CDN（内容分发网络）与网络安全基础设施提供商。
2. 核心三大件：
- Pages (前端页面)：依托边缘节点提供全球 CDN 加速。访问人数越多，边缘缓存命中率越高，响应速度越快。
- Worker (后端逻辑)：采用 V8 引擎的按需计算单元。请求到达时瞬间启动，处理完毕即销毁。具备极强的并发处理能力，系统会自动横向扩展应对大规模访问。
- D1 Database (数据库)：基于 SQLite 的边缘存储服务，用于结构化数据的持久化保存。
## 三、 核心配置文件流转逻辑
1. 后端配置 (wrangler.toml)：
- 存在于后端项目中，定义 Worker 运行所需的云端资源清单。
- 包含绑定的域名 (DOMAINS)、挂载的数据库实例 ID 等核心参数。
- 修改此文件后，必须执行 `wrangler deploy` 重新部署至云端方可生效。
2. 前端环境配置 (.env)：
- 存在于前端项目中，用于在打包时注入环境变量。
- `VITE_API_BASE` 变量充当桥梁，为静态前端网页指明后端 Worker API 的网络访问地址。
3. 数据库初始化：
- 建立 D1 数据库实例后，必须执行对应的 schema.sql 文件来构建数据表结构，前端才能正常写入数据。
## 四、 现代 Web 风控与反欺诈机制 (Risk Control)
1. 综合评分体系：
- 大型互联网平台的风控系统采用多维度 AI 模型进行交叉验证，决定操作的放行概率。
2. 核心提分维度：
- 行为特征：模拟真实用户频率，使用规律的英文名称作为邮箱前缀，避免短时间高并发请求。
- 域名年龄：域名注册满 1-3 个月后，会自动脱离新域名的“沙盒期”，获得更高的基础信誉分。
- 域名后缀 (TLD)：高价值后缀（如 .com、.org）具备更高的初始信誉分。
- 邮件服务器 (MX)：使用顶级付费企业邮箱可获得附加信誉分。
## 五、 技术选型：Serverless vs 传统 VPS
1. Serverless (如 Cloudflare) 适用场景：
- 适合临时邮箱、轻量级 API、静态博客等“即用即走”、高并发、需要免维护防御的 Web 项目。
- 运行环境轻量，单次请求限制在几十毫秒 CPU 时间内。
2. 传统 VPS (自有服务器) 适用场景：
- 适合运行 DrissionPage 等复杂爬虫、游戏私服、需要 24 小时后台挂机的长驻程序。
- 提供完整的操作系统权限，支持安装各类浏览器驱动和底层系统级环境。
====================================================================
Cloudflare 云原生架构与 Web 运维核心知识库
====================================================================
## 一、 域名与 DNS 解析原理
1. 角色分工：
- 域名注册商（如 Spaceship）：负责在互联网总账本中登记域名的所有权。
- DNS 托管商（如 Cloudflare）：负责接管域名的流量调度和解析记录管理。
2. 寻址与生效机制：
- 客户端访问域名时，会通过全球 DNS 系统查询目标服务器的 IP 地址。
- 修改 DNS 记录后，全球各地的运营商节点更新缓存通常需要 15 到 30 分钟的时间。
3. MX 记录 (Mail Exchanger)：
- 专用于电子邮件系统的解析记录，指示全网将发往该域名的邮件派送到指定的邮件服务器。
## 二、 Cloudflare Serverless (无服务) 架构体系
1. 平台定位：
- Cloudflare 是一家全球顶级的 CDN（内容分发网络）与网络安全基础设施提供商。
2. 核心三大件：
- Pages (前端页面)：依托边缘节点提供全球 CDN 加速。访问人数越多，边缘缓存命中率越高，响应速度越快。
- Worker (后端逻辑)：采用 V8 引擎的按需计算单元。请求到达时瞬间启动，处理完毕即销毁。具备极强的并发处理能力，系统会自动横向扩展应对大规模访问。
- D1 Database (数据库)：基于 SQLite 的边缘存储服务，用于结构化数据的持久化保存。
## 三、 核心配置文件流转逻辑
1. 后端配置 (wrangler.toml)：
- 存在于后端项目中，定义 Worker 运行所需的云端资源清单。
- 包含绑定的域名 (DOMAINS)、挂载的数据库实例 ID 等核心参数。
- 修改此文件后，必须执行 `wrangler deploy` 重新部署至云端方可生效。
2. 前端环境配置 (.env)：
- 存在于前端项目中，用于在打包时注入环境变量。
- `VITE_API_BASE` 变量充当桥梁，为静态前端网页指明后端 Worker API 的网络访问地址。
3. 数据库初始化：
- 建立 D1 数据库实例后，必须执行对应的 schema.sql 文件来构建数据表结构，前端才能正常写入数据。
## 四、 现代 Web 风控与反欺诈机制 (Risk Control)
1. 综合评分体系：
- 大型互联网平台的风控系统采用多维度 AI 模型进行交叉验证，决定操作的放行概率。
2. 核心提分维度：
- 行为特征：模拟真实用户频率，使用规律的英文名称作为邮箱前缀，避免短时间高并发请求。
- 域名年龄：域名注册满 1-3 个月后，会自动脱离新域名的“沙盒期”，获得更高的基础信誉分。
- 域名后缀 (TLD)：高价值后缀（如 .com、.org）具备更高的初始信誉分。
- 邮件服务器 (MX)：使用顶级付费企业邮箱可获得附加信誉分。
## 五、 技术选型：Serverless vs 传统 VPS
1. Serverless (如 Cloudflare) 适用场景：
- 适合临时邮箱、轻量级 API、静态博客等“即用即走”、高并发、需要免维护防御的 Web 项目。
- 运行环境轻量，单次请求限制在几十毫秒 CPU 时间内。
2. 传统 VPS (自有服务器) 适用场景：
- 适合运行 DrissionPage 等复杂爬虫、游戏私服、需要 24 小时后台挂机的长驻程序。
- 提供完整的操作系统权限，支持安装各类浏览器驱动和底层系统级环境。
# VPN Reality 协议
这个问题就是纯技术原理,讲清楚 TLS 指纹的来龙去脉。
## 一、什么是 TLS 指纹
当你访问一个 HTTPS 网站,浏览器和服务器在发任何 HTTP 数据之前,要先做 **TLS 握手**(TLS Handshake)建立加密通道。握手的第一步就是客户端发一个叫 **ClientHello** 的数据包,告诉服务器:
- 我支持哪些 TLS 版本(1.2 / 1.3)
- 我支持哪些加密套件(Cipher Suites)
- 我支持哪些扩展(Extensions)
- 我支持哪些椭圆曲线(Elliptic Curves)
- 我支持哪些签名算法
- 我支持哪些 ALPN 协议(http/1.1, h2, h3)
- ... 等等几十个字段
**关键点**:不同的客户端发出来的 ClientHello **长得不一样**。Chrome 发的、Firefox 发的、Python requests 发的、curl 发的、Java HttpClient 发的,每一种都有自己独特的"长相"。
把这些字段按一定规则提取出来、哈希一下,就得到一个**指纹**。这就是 TLS 指纹。
## 二、JA3 和 JA4
### JA3(老一代,2017 年出的)
JA3 由 Salesforce 的安全团队提出,从 ClientHello 里提取 5 个字段:
```
SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat
```
具体做法:把这些字段的值按顺序用逗号拼起来,再 MD5。
举个例子,Chrome 的 JA3 字符串可能长这样:
```
771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513,29-23-24,0
```
MD5 之后:
```
cd08e31494f9531f560d64c695473da9
```
服务器拿到 ClientHello 后,自己算一遍 MD5,跟"已知的 Chrome JA3"对比 → 如果匹配就是 Chrome,如果是 Python requests 那个特定的 MD5 → 直接判 bot。
### JA4(新一代,2023 年由 FoxIO 推出)
JA4 是 JA3 的升级版,解决了 JA3 的几个问题:
1. **JA3 太脆弱**:Chrome 给 ClientHello 加了 GREASE(故意往字段里塞随机值,扰乱指纹),JA3 就被打乱了
2. **MD5 不可读**:JA3 算出来就是一坨 32 位十六进制,看不出任何信息
3. **JA3 没区分 TLS 版本和 ALPN**
JA4 的格式更结构化:
```
t13d1516h2_8daaf6152771_b186095e22b6
```
拆开来:
- `t13` = TCP + TLS 1.3
- `d` = 有 SNI(域名指示)
- `1516` = 21 个 cipher / 16 个 extension
- `h2` = HTTP/2 ALPN
- `8daaf6152771` = cipher 列表的 SHA256 前 12 位
- `b186095e22b6` = extension + 签名算法的 SHA256 前 12 位
JA4 还衍生出了一整套指纹族:JA4S(服务端响应)、JA4H(HTTP 请求头)、JA4L(延迟)、JA4T(TCP 选项)、JA4X(X.509 证书)等,组合起来识别能力极强。
现在 Akamai、Cloudflare、F5 这类大厂的 WAF 都用 JA4 系列了,JA3 已经基本被淘汰。
## 三、为什么 Python 请求库会暴露
来看几个不同库的"长相差异":
### Python `requests` 库
`requests` 底层用 `urllib3`,`urllib3` 用 Python 标准库的 `ssl` 模块,`ssl` 模块包装 OpenSSL。
OpenSSL 默认支持的 cipher suite 和 extension 顺序,跟 Chrome **完全不一样**。比如:
- Python 默认会发 `0x00ff` (TLS_EMPTY_RENEGOTIATION_INFO) 这个 cipher,Chrome 不发
- Python 的 extension 顺序是固定的递增数字(0, 5, 10, 11, 13...),Chrome 是 GREASE 打乱过的
- Python 默认不发 `application_settings` extension,Chrome 发
- Python 默认不发 `compress_certificate` extension,Chrome 发
任何一个 WAF 一看 ClientHello,立刻就能算出 JA3 = `Python requests 的指纹`,直接拦。
### `curl` 命令行
curl 用 OpenSSL/GnuTLS/NSS 之一,跟 Python 略有不同但也是固定的指纹。安全社区维护了一个公开数据库 [https://tlsfingerprint.io](https://tlsfingerprint.io),把所有常见客户端的 JA3/JA4 都收录了,服务器拿到一个指纹一查就知道你是什么。
### Chrome / Firefox
它们有自己的 TLS 实现:
- Chrome 用 **BoringSSL**(Google 自己 fork 的 OpenSSL)
- Firefox 用 **NSS**
这两个库实现 ClientHello 的方式跟 OpenSSL 差异很大,而且会跟着浏览器版本变化。
## 四、curl_cffi 是怎么解决的
### 它的实现思路
curl_cffi 不是从头实现 TLS,而是**用 Python 调用了 curl-impersonate**。
curl-impersonate 是一个**特别版本的 curl**,作者(lwthiker)做了一件事:**修改 curl 的源码,把它的 TLS 实现替换成 BoringSSL,并精确还原 Chrome 的 ClientHello 行为**。
具体改了:
- 把 OpenSSL 换成 BoringSSL(和 Chrome 同款)
- 修改 cipher suite 列表,完全照抄 Chrome 的顺序
- 修改 extension 列表和顺序
- 加上 GREASE 随机值(Chrome 特有)
- 调整 HTTP/2 SETTINGS 帧的字段顺序(这是 HTTP/2 层的指纹,叫 Akamai HTTP/2 fingerprint)
- 调整 HTTP header 的顺序和大小写
编译出来一个 `curl_chrome120` 的二进制,跑起来发出的请求,从 TLS 到 HTTP/2 到 HTTP header,**和真实 Chrome 120 一模一样**。
curl_cffi 用 cffi(C Foreign Function Interface)把这个二进制包装成 Python 可调用的库。
### 用起来是这样
```python
from curl_cffi import requests
# API 跟 requests 几乎一样
resp = requests.get(
'https://tls.peet.ws/api/all',
impersonate='chrome120' # 关键参数,指定要伪装成什么
)
print(resp.json())
```
`impersonate` 参数支持的值很多:
```
chrome99, chrome100, chrome101, chrome104, chrome107, chrome110,
chrome116, chrome119, chrome120, chrome123, chrome124, chrome131,
chrome99_android, chrome131_android,
edge99, edge101,
safari15_3, safari15_5, safari17_0, safari17_2_ios, safari18_0,
firefox133, firefox135,
...
```
每个对应一组精确还原的指纹。
### 验证一下
有几个网站专门用来验证你的 TLS 指纹长什么样:
```python
# 用普通 requests
import requests as std_req
r = std_req.get('https://tls.peet.ws/api/all').json()
print('普通 requests JA3:', r['tls']['ja3_hash'])
# 输出类似: 5d1d92b8b25d0f0ca58a4f3f6f38e9c2 (Python 特征)
# 用 curl_cffi
from curl_cffi import requests as cf_req
r = cf_req.get('https://tls.peet.ws/api/all', impersonate='chrome120').json()
print('curl_cffi JA3:', r['tls']['ja3_hash'])
# 输出类似: cd08e31494f9531f560d64c695473da9 (Chrome 特征)
```
测试站点:
- `https://tls.peet.ws/api/all` —— 详细的 TLS+HTTP2 指纹
- `https://tls.browserleaks.com/json` —— BrowserLeaks 的检测
- `https://check.ja4.app` —— JA4 专门检测
## 五、curl_cffi 的边界:它解决什么、不解决什么
### ✅ 解决
| 层 | 指纹 | curl_cffi 处理 |
| --- | --- | --- |
| TCP | TCP options 顺序 | ❌ 不处理(系统层) |
| TLS | JA3 (cipher/ext/curve) | ✅ |
| TLS | JA4 (新版聚合指纹) | ✅ |
| TLS | GREASE 随机值 | ✅ |
| TLS | ALPN 顺序 | ✅ |
| HTTP/2 | SETTINGS 帧字段顺序(Akamai 指纹) | ✅ |
| HTTP/2 | WINDOW_UPDATE 数值 | ✅ |
| HTTP/2 | HEADERS 帧的伪头顺序 | ✅ |
| HTTP | header 顺序和大小写 | ✅ |
这些是 curl_cffi 相比 requests 的核心优势,也是它存在的理由。
### ❌ 不解决
| 层 | 内容 | 谁负责 |
| --- | --- | --- |
| 应用层 | Cookie 管理 | 你自己代码 |
| 应用层 | 加密参数生成(`X-Bogus`, `_signature`, `sensor_data` 等) | 你 JS 逆向 |
| 应用层 | Canvas/WebGL/Audio 指纹 | 浏览器才有 |
| 应用层 | 鼠标轨迹、按键间隔 | 浏览器才有 |
| 应用层 | localStorage/IndexedDB | 浏览器才有 |
| 网络层 | TCP/IP 指纹(p0f) | 操作系统 |
| 网络层 | IP 信誉(住宅 vs 数据中心) | 你的代理 |
**所以 curl_cffi 是"伪装传输层",不是"伪装浏览器"**。它让你的请求在网络层面看起来像 Chrome,但浏览器里那一大堆 JS 运行时特征,它管不到。
## 六、几个常被混淆的概念
### TLS 指纹 ≠ User-Agent
UA 是 HTTP 请求头里的一行字符串,**改一下太容易了**(`headers={'User-Agent': 'xxx'}`)。但 TLS 指纹是在 HTTP 之前的握手层,**改 UA 不影响 TLS 指纹**。
很多新手看到反爬就改 UA,但服务器看 JA3 就发现:UA 写的 Chrome,TLS 长得像 Python,**矛盾即 bot**。
### TLS 指纹 ≠ TLS 加密强度
加密强度看的是握手完之后用什么算法加解密数据。TLS 指纹只看握手过程"协商时提供了哪些选项",和最终用了哪个算法没关系。
### curl_cffi ≠ 万能反爬
我看到太多人以为 `pip install curl_cffi` + `impersonate='chrome120'` 就能搞定一切。**完全错**。
它只是把"网络层穿过去"这一步做了。如果对方上了 JS 加密参数(比如 Cloudflare Turnstile 的 `cf-turnstile-response`),curl_cffi 不管这个,你还是得逆 JS 或者跑无头浏览器拿 token。
curl_cffi 的最佳搭配场景是:
1. **简单接口反爬**:对方只校验 TLS 和 header,没有 JS 加密 → curl_cffi 单兵作战
2. **混合方案**:浏览器扛过登录拿到 cookie/token → 切到 curl_cffi 跑业务接口,效率拉满
3. **Mobile API**:很多 App 用 OkHttp 之类的库,有自己的 TLS 指纹,curl_cffi 也能伪装(`impersonate='okhttp4_android10'`)
## 七、和它类似的工具
| 库 | 语言 | 原理 |
| --- | --- | --- |
| **curl_cffi** | Python | curl-impersonate 的 Python 绑定 |
| **tls-client** | Python/Go | 基于 Go 的 utls 库,纯 Go 实现 TLS |
| **rnet** | Python | 基于 Rust 的 boring 库 |
| **primp** | Python | 基于 Rust 的 reqwest+rquest |
| **httpx** + **wassima** | Python | 部分支持 |
| **utls** | Go | Go 生态最有名的伪装库 |
| **CycleTLS** | Node.js | Node 生态的对应物 |
curl_cffi 目前是 Python 生态里**生态最成熟、impersonate 选项最全**的,所以用得最多。tls-client 性能更好但 impersonate 选项稍少。
## 总结
- **TLS 指纹** = ClientHello 数据包字段组合的哈希,**JA3 是老版,JA4 是新版**
- **暴露原因** = 不同库/浏览器的 TLS 实现细节不同,WAF 对比指纹库就能识别
- **curl_cffi** = 调用 curl-impersonate 二进制,在网络栈层面精确复刻 Chrome 的 ClientHello + HTTP/2 行为
- **能力边界** = 只解决传输层伪装,不解决应用层加密参数和浏览器运行时指纹
理解了这个,你就明白为什么有些场景"requests 死活进不去,curl_cffi 一行就过了",也明白为什么有些场景"curl_cffi 也救不了,必须开浏览器"。
一. 关于 cURL 的概念
cURL 的全称是 Client URL。它是一个利用 URL 语法在命令行下工作的文件传输工具。在 Web 逆向和抓包领域，它最伟大的作用就是完美保存了一次网络请求的所有上下文（包括方法、URL、完整的请求头 Header、所有的 Cookie 以及载荷 Body）。
有了这个格式，你不仅可以直接在终端里运行它来重发请求，还可以利用工具（比如 Postman 或者一些在线的 cURL to Python 转换器）一键把它转化成标准的 Python requests 或 curl_cffi 代码。
二、如何肉眼分辨“遥测系统（Datadog）”和“风控系统（Challenge）”？
你提到的“直接复制 cURL 检查字段”是一个好思路，但更高效的方法是在浏览器的 Network（网络）面板里，像看病理报告一样看以下四个核心特征：
1. 看 URL 和域名（看名字）
遥测狗（可杀）： 域名或路径通常包含 track, collect, intake, logs, metrics, events。比如 Datadog 的接收接口通常长这样：https://browser-intake-datadoghq.com/api/v2/logs...
风控保安（不可杀）： 域名通常是主业务域名（比如乐天的 login.account.rakuten.com），或者专门的风控厂商域名。路径里常带有 challenge, verify, bot, captcha, registration。
2. 看 Payload（看它收集了什么）
遥测狗（可杀）： 它的 Payload 往往是人类可读的明文 JSON。你打开一看，里面记着：屏幕分辨率 1920x1080、页面停留了 1250ms、刚才点了一下 submit_button、甚至有几条 JS 报错日志。
风控保安（不可杀）： 它的 Payload 是一大坨人类绝对看不懂的乱码/Base64/高强度加密字符串。比如你之前抓到的那个 @St.ott-v2... 开头的几千个字符的 token。
3. 看 Response（看服务器给什么回执）
遥测狗（可杀）： 典型的“只读不回”或者“敷衍了事”。服务器通常返回状态码 204 No Content（收到，没话说），或者返回一个极简的 {"success": true}。最重要的是，它的响应结果，你的下一步业务根本用不到。
风控保安（不可杀）： 服务器的响应极其重要。它要么给你下发一个非常关键的 Set-Cookie（用来证明你通过了环境检测），要么在 Response Body 里给你一个 session_token，要求你在紧接着发出的下一步请求中带上它。
4. 终极验证法：Chrome 断点拦截法（不用写代码就能测）
如果你看了上面的特征还是拿不准，不要着急写代码，直接在浏览器里测：
打开浏览器的 F12 开发者工具，进入 Network 面板。
找到那个你怀疑的请求，右键点击它，选择 Block request URL（阻止请求网址）。
刷新页面，或者重新点一下“注册/登录”按钮。
看结果： 如果业务顺利走下去了，说明这是条“遥测狗”，大胆在代码里屏蔽它；如果页面弹红字报错、一直转圈圈、或者报 400/403 错误，说明这是“风控保安”，你必须得想办法处理它。
HAR 是什么 —— 完整解释
HAR = HTTP Archive,是 W3C 草案级别的标准格式,本质就是个 JSON 文件,把一段时间内浏览器(或抓包工具)记录的所有 HTTP 请求和响应,按结构化格式打包保存。
全称展开:HTTP Archive format
文件扩展名:.har
MIME 类型:application/json(它就是 JSON,只是约定俗成用 .har 后缀)
HAR 的顶层结构
json{
"log": {
"version": "1.2", // HAR 规范版本,目前主流是 1.2
"creator": { ... }, // 谁生成的这个文件(浏览器/工具/扩展)
"browser": { ... }, // 用户浏览器信息
"pages": [ ... ], // 页面级别的元数据(标题、加载时间等)
"entries": [ ... ] // 核心:所有请求/响应的数组
}
}
每个 entry 包含什么
一条 entry 就是一次完整的请求-响应往返,典型字段:
字段含义startedDateTime请求发起的精确时间(ISO 8601)time整个请求的总耗时(毫秒)request请求详情:method、URL、HTTP 版本、headers、cookies、query string、postData(body)response响应详情:状态码、headers、cookies、content(body)cache缓存命中情况timings详细的时间分解:DNS、TCP 握手、TLS、等待、接收等各阶段耗时serverIPAddress服务器实际 IPconnectionTCP 连接 ID_initiator(非标准但常见)谁发起了这个请求(JS 脚本?重定向?)
HAR 能干什么
流量分析:整个页面加载过程一目了然,哪个请求慢、哪个 4xx/5xx
性能审计:WebPageTest、GTmetrix 这类工具基本都基于 HAR
接口研究(你的场景):看清整个业务流程的 API 调用顺序和参数
请求重放:导入 Postman / Insomnia 后挑选请求重新发送
问题排查:用户报 bug 时让用户导个 HAR 发过来,工程师能精确还原现场
自动化生成测试:有工具能把 HAR 转成 Playwright / k6 等测试脚本
这个问题就是纯技术原理,讲清楚 TLS 指纹的来龙去脉。
## 一、什么是 TLS 指纹
当你访问一个 HTTPS 网站,浏览器和服务器在发任何 HTTP 数据之前,要先做 **TLS 握手**(TLS Handshake)建立加密通道。握手的第一步就是客户端发一个叫 **ClientHello** 的数据包,告诉服务器:
- 我支持哪些 TLS 版本(1.2 / 1.3)
- 我支持哪些加密套件(Cipher Suites)
- 我支持哪些扩展(Extensions)
- 我支持哪些椭圆曲线(Elliptic Curves)
- 我支持哪些签名算法
- 我支持哪些 ALPN 协议(http/1.1, h2, h3)
- ... 等等几十个字段
**关键点**:不同的客户端发出来的 ClientHello **长得不一样**。Chrome 发的、Firefox 发的、Python requests 发的、curl 发的、Java HttpClient 发的,每一种都有自己独特的"长相"。
把这些字段按一定规则提取出来、哈希一下,就得到一个**指纹**。这就是 TLS 指纹。
## 二、JA3 和 JA4
### JA3(老一代,2017 年出的)
JA3 由 Salesforce 的安全团队提出,从 ClientHello 里提取 5 个字段:
```
SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat
```
具体做法:把这些字段的值按顺序用逗号拼起来,再 MD5。
举个例子,Chrome 的 JA3 字符串可能长这样:
```
771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513,29-23-24,0
```
MD5 之后:
```
cd08e31494f9531f560d64c695473da9
```
服务器拿到 ClientHello 后,自己算一遍 MD5,跟"已知的 Chrome JA3"对比 → 如果匹配就是 Chrome,如果是 Python requests 那个特定的 MD5 → 直接判 bot。
### JA4(新一代,2023 年由 FoxIO 推出)
JA4 是 JA3 的升级版,解决了 JA3 的几个问题:
1. **JA3 太脆弱**:Chrome 给 ClientHello 加了 GREASE(故意往字段里塞随机值,扰乱指纹),JA3 就被打乱了
2. **MD5 不可读**:JA3 算出来就是一坨 32 位十六进制,看不出任何信息
3. **JA3 没区分 TLS 版本和 ALPN**
JA4 的格式更结构化:
```
t13d1516h2_8daaf6152771_b186095e22b6
```
拆开来:
- `t13` = TCP + TLS 1.3
- `d` = 有 SNI(域名指示)
- `1516` = 21 个 cipher / 16 个 extension
- `h2` = HTTP/2 ALPN
- `8daaf6152771` = cipher 列表的 SHA256 前 12 位
- `b186095e22b6` = extension + 签名算法的 SHA256 前 12 位
JA4 还衍生出了一整套指纹族:JA4S(服务端响应)、JA4H(HTTP 请求头)、JA4L(延迟)、JA4T(TCP 选项)、JA4X(X.509 证书)等,组合起来识别能力极强。
现在 Akamai、Cloudflare、F5 这类大厂的 WAF 都用 JA4 系列了,JA3 已经基本被淘汰。
## 三、为什么 Python 请求库会暴露
来看几个不同库的"长相差异":
### Python `requests` 库
`requests` 底层用 `urllib3`,`urllib3` 用 Python 标准库的 `ssl` 模块,`ssl` 模块包装 OpenSSL。
OpenSSL 默认支持的 cipher suite 和 extension 顺序,跟 Chrome **完全不一样**。比如:
- Python 默认会发 `0x00ff` (TLS_EMPTY_RENEGOTIATION_INFO) 这个 cipher,Chrome 不发
- Python 的 extension 顺序是固定的递增数字(0, 5, 10, 11, 13...),Chrome 是 GREASE 打乱过的
- Python 默认不发 `application_settings` extension,Chrome 发
- Python 默认不发 `compress_certificate` extension,Chrome 发
任何一个 WAF 一看 ClientHello,立刻就能算出 JA3 = `Python requests 的指纹`,直接拦。
### `curl` 命令行
curl 用 OpenSSL/GnuTLS/NSS 之一,跟 Python 略有不同但也是固定的指纹。安全社区维护了一个公开数据库 [https://tlsfingerprint.io](https://tlsfingerprint.io),把所有常见客户端的 JA3/JA4 都收录了,服务器拿到一个指纹一查就知道你是什么。
### Chrome / Firefox
它们有自己的 TLS 实现:
- Chrome 用 **BoringSSL**(Google 自己 fork 的 OpenSSL)
- Firefox 用 **NSS**
这两个库实现 ClientHello 的方式跟 OpenSSL 差异很大,而且会跟着浏览器版本变化。
## 四、curl_cffi 是怎么解决的
### 它的实现思路
curl_cffi 不是从头实现 TLS,而是**用 Python 调用了 curl-impersonate**。
curl-impersonate 是一个**特别版本的 curl**,作者(lwthiker)做了一件事:**修改 curl 的源码,把它的 TLS 实现替换成 BoringSSL,并精确还原 Chrome 的 ClientHello 行为**。
具体改了:
- 把 OpenSSL 换成 BoringSSL(和 Chrome 同款)
- 修改 cipher suite 列表,完全照抄 Chrome 的顺序
- 修改 extension 列表和顺序
- 加上 GREASE 随机值(Chrome 特有)
- 调整 HTTP/2 SETTINGS 帧的字段顺序(这是 HTTP/2 层的指纹,叫 Akamai HTTP/2 fingerprint)
- 调整 HTTP header 的顺序和大小写
编译出来一个 `curl_chrome120` 的二进制,跑起来发出的请求,从 TLS 到 HTTP/2 到 HTTP header,**和真实 Chrome 120 一模一样**。
curl_cffi 用 cffi(C Foreign Function Interface)把这个二进制包装成 Python 可调用的库。
### 用起来是这样
```python
from curl_cffi import requests
# API 跟 requests 几乎一样
resp = requests.get(
'https://tls.peet.ws/api/all',
impersonate='chrome120' # 关键参数,指定要伪装成什么
)
print(resp.json())
```
`impersonate` 参数支持的值很多:
```
chrome99, chrome100, chrome101, chrome104, chrome107, chrome110,
chrome116, chrome119, chrome120, chrome123, chrome124, chrome131,
chrome99_android, chrome131_android,
edge99, edge101,
safari15_3, safari15_5, safari17_0, safari17_2_ios, safari18_0,
firefox133, firefox135,
...
```
每个对应一组精确还原的指纹。
### 验证一下
有几个网站专门用来验证你的 TLS 指纹长什么样:
```python
# 用普通 requests
import requests as std_req
r = std_req.get('https://tls.peet.ws/api/all').json()
print('普通 requests JA3:', r['tls']['ja3_hash'])
# 输出类似: 5d1d92b8b25d0f0ca58a4f3f6f38e9c2 (Python 特征)
# 用 curl_cffi
from curl_cffi import requests as cf_req
r = cf_req.get('https://tls.peet.ws/api/all', impersonate='chrome120').json()
print('curl_cffi JA3:', r['tls']['ja3_hash'])
# 输出类似: cd08e31494f9531f560d64c695473da9 (Chrome 特征)
```
测试站点:
- `https://tls.peet.ws/api/all` —— 详细的 TLS+HTTP2 指纹
- `https://tls.browserleaks.com/json` —— BrowserLeaks 的检测
- `https://check.ja4.app` —— JA4 专门检测
## 五、curl_cffi 的边界:它解决什么、不解决什么
### ✅ 解决
| 层 | 指纹 | curl_cffi 处理 |
| --- | --- | --- |
| TCP | TCP options 顺序 | ❌ 不处理(系统层) |
| TLS | JA3 (cipher/ext/curve) | ✅ |
| TLS | JA4 (新版聚合指纹) | ✅ |
| TLS | GREASE 随机值 | ✅ |
| TLS | ALPN 顺序 | ✅ |
| HTTP/2 | SETTINGS 帧字段顺序(Akamai 指纹) | ✅ |
| HTTP/2 | WINDOW_UPDATE 数值 | ✅ |
| HTTP/2 | HEADERS 帧的伪头顺序 | ✅ |
| HTTP | header 顺序和大小写 | ✅ |
这些是 curl_cffi 相比 requests 的核心优势,也是它存在的理由。
### ❌ 不解决
| 层 | 内容 | 谁负责 |
| --- | --- | --- |
| 应用层 | Cookie 管理 | 你自己代码 |
| 应用层 | 加密参数生成(`X-Bogus`, `_signature`, `sensor_data` 等) | 你 JS 逆向 |
| 应用层 | Canvas/WebGL/Audio 指纹 | 浏览器才有 |
| 应用层 | 鼠标轨迹、按键间隔 | 浏览器才有 |
| 应用层 | localStorage/IndexedDB | 浏览器才有 |
| 网络层 | TCP/IP 指纹(p0f) | 操作系统 |
| 网络层 | IP 信誉(住宅 vs 数据中心) | 你的代理 |
**所以 curl_cffi 是"伪装传输层",不是"伪装浏览器"**。它让你的请求在网络层面看起来像 Chrome,但浏览器里那一大堆 JS 运行时特征,它管不到。
## 六、几个常被混淆的概念
### TLS 指纹 ≠ User-Agent
UA 是 HTTP 请求头里的一行字符串,**改一下太容易了**(`headers={'User-Agent': 'xxx'}`)。但 TLS 指纹是在 HTTP 之前的握手层,**改 UA 不影响 TLS 指纹**。
很多新手看到反爬就改 UA,但服务器看 JA3 就发现:UA 写的 Chrome,TLS 长得像 Python,**矛盾即 bot**。
### TLS 指纹 ≠ TLS 加密强度
加密强度看的是握手完之后用什么算法加解密数据。TLS 指纹只看握手过程"协商时提供了哪些选项",和最终用了哪个算法没关系。
### curl_cffi ≠ 万能反爬
我看到太多人以为 `pip install curl_cffi` + `impersonate='chrome120'` 就能搞定一切。**完全错**。
它只是把"网络层穿过去"这一步做了。如果对方上了 JS 加密参数(比如 Cloudflare Turnstile 的 `cf-turnstile-response`),curl_cffi 不管这个,你还是得逆 JS 或者跑无头浏览器拿 token。
curl_cffi 的最佳搭配场景是:
1. **简单接口反爬**:对方只校验 TLS 和 header,没有 JS 加密 → curl_cffi 单兵作战
2. **混合方案**:浏览器扛过登录拿到 cookie/token → 切到 curl_cffi 跑业务接口,效率拉满
3. **Mobile API**:很多 App 用 OkHttp 之类的库,有自己的 TLS 指纹,curl_cffi 也能伪装(`impersonate='okhttp4_android10'`)
## 七、和它类似的工具
| 库 | 语言 | 原理 |
| --- | --- | --- |
| **curl_cffi** | Python | curl-impersonate 的 Python 绑定 |
| **tls-client** | Python/Go | 基于 Go 的 utls 库,纯 Go 实现 TLS |
| **rnet** | Python | 基于 Rust 的 boring 库 |
| **primp** | Python | 基于 Rust 的 reqwest+rquest |
| **httpx** + **wassima** | Python | 部分支持 |
| **utls** | Go | Go 生态最有名的伪装库 |
| **CycleTLS** | Node.js | Node 生态的对应物 |
curl_cffi 目前是 Python 生态里**生态最成熟、impersonate 选项最全**的,所以用得最多。tls-client 性能更好但 impersonate 选项稍少。
## 总结
- **TLS 指纹** = ClientHello 数据包字段组合的哈希,**JA3 是老版,JA4 是新版**
- **暴露原因** = 不同库/浏览器的 TLS 实现细节不同,WAF 对比指纹库就能识别
- **curl_cffi** = 调用 curl-impersonate 二进制,在网络栈层面精确复刻 Chrome 的 ClientHello + HTTP/2 行为
- **能力边界** = 只解决传输层伪装,不解决应用层加密参数和浏览器运行时指纹
理解了这个,你就明白为什么有些场景"requests 死活进不去,curl_cffi 一行就过了",也明白为什么有些场景"curl_cffi 也救不了,必须开浏览器"。
一. 关于 cURL 的概念
cURL 的全称是 Client URL。它是一个利用 URL 语法在命令行下工作的文件传输工具。在 Web 逆向和抓包领域，它最伟大的作用就是完美保存了一次网络请求的所有上下文（包括方法、URL、完整的请求头 Header、所有的 Cookie 以及载荷 Body）。
有了这个格式，你不仅可以直接在终端里运行它来重发请求，还可以利用工具（比如 Postman 或者一些在线的 cURL to Python 转换器）一键把它转化成标准的 Python requests 或 curl_cffi 代码。
二、如何肉眼分辨“遥测系统（Datadog）”和“风控系统（Challenge）”？
你提到的“直接复制 cURL 检查字段”是一个好思路，但更高效的方法是在浏览器的 Network（网络）面板里，像看病理报告一样看以下四个核心特征：
1. 看 URL 和域名（看名字）
遥测狗（可杀）： 域名或路径通常包含 track, collect, intake, logs, metrics, events。比如 Datadog 的接收接口通常长这样：https://browser-intake-datadoghq.com/api/v2/logs...
风控保安（不可杀）： 域名通常是主业务域名（比如乐天的 login.account.rakuten.com），或者专门的风控厂商域名。路径里常带有 challenge, verify, bot, captcha, registration。
2. 看 Payload（看它收集了什么）
遥测狗（可杀）： 它的 Payload 往往是人类可读的明文 JSON。你打开一看，里面记着：屏幕分辨率 1920x1080、页面停留了 1250ms、刚才点了一下 submit_button、甚至有几条 JS 报错日志。
风控保安（不可杀）： 它的 Payload 是一大坨人类绝对看不懂的乱码/Base64/高强度加密字符串。比如你之前抓到的那个 @St.ott-v2... 开头的几千个字符的 token。
3. 看 Response（看服务器给什么回执）
遥测狗（可杀）： 典型的“只读不回”或者“敷衍了事”。服务器通常返回状态码 204 No Content（收到，没话说），或者返回一个极简的 {"success": true}。最重要的是，它的响应结果，你的下一步业务根本用不到。
风控保安（不可杀）： 服务器的响应极其重要。它要么给你下发一个非常关键的 Set-Cookie（用来证明你通过了环境检测），要么在 Response Body 里给你一个 session_token，要求你在紧接着发出的下一步请求中带上它。
4. 终极验证法：Chrome 断点拦截法（不用写代码就能测）
如果你看了上面的特征还是拿不准，不要着急写代码，直接在浏览器里测：
打开浏览器的 F12 开发者工具，进入 Network 面板。
找到那个你怀疑的请求，右键点击它，选择 Block request URL（阻止请求网址）。
刷新页面，或者重新点一下“注册/登录”按钮。
看结果： 如果业务顺利走下去了，说明这是条“遥测狗”，大胆在代码里屏蔽它；如果页面弹红字报错、一直转圈圈、或者报 400/403 错误，说明这是“风控保安”，你必须得想办法处理它。
HAR 是什么 —— 完整解释
HAR = HTTP Archive,是 W3C 草案级别的标准格式,本质就是个 JSON 文件,把一段时间内浏览器(或抓包工具)记录的所有 HTTP 请求和响应,按结构化格式打包保存。
全称展开:HTTP Archive format
文件扩展名:.har
MIME 类型:application/json(它就是 JSON,只是约定俗成用 .har 后缀)
HAR 的顶层结构
json{
"log": {
"version": "1.2", // HAR 规范版本,目前主流是 1.2
"creator": { ... }, // 谁生成的这个文件(浏览器/工具/扩展)
"browser": { ... }, // 用户浏览器信息
"pages": [ ... ], // 页面级别的元数据(标题、加载时间等)
"entries": [ ... ] // 核心:所有请求/响应的数组
}
}
每个 entry 包含什么
一条 entry 就是一次完整的请求-响应往返,典型字段:
字段含义startedDateTime请求发起的精确时间(ISO 8601)time整个请求的总耗时(毫秒)request请求详情:method、URL、HTTP 版本、headers、cookies、query string、postData(body)response响应详情:状态码、headers、cookies、content(body)cache缓存命中情况timings详细的时间分解:DNS、TCP 握手、TLS、等待、接收等各阶段耗时serverIPAddress服务器实际 IPconnectionTCP 连接 ID_initiator(非标准但常见)谁发起了这个请求(JS 脚本?重定向?)
HAR 能干什么
流量分析:整个页面加载过程一目了然,哪个请求慢、哪个 4xx/5xx
性能审计:WebPageTest、GTmetrix 这类工具基本都基于 HAR
接口研究(你的场景):看清整个业务流程的 API 调用顺序和参数
请求重放:导入 Postman / Insomnia 后挑选请求重新发送
问题排查:用户报 bug 时让用户导个 HAR 发过来,工程师能精确还原现场
自动化生成测试:有工具能把 HAR 转成 Playwright / k6 等测试脚本
# 服务器与网络核心概念笔记
服务器与网络核心概念笔记
## 核心笔记一：X-UI 终端乱码的真相
X-UI 安装脚本使用的是标准的 UTF-8 中文编码，本身没有任何问题。
乱码的原因在于“显示器”不对： 你当时使用的是服务商（SolusVM 控制面板）自带的网页版 VNC 终端。这种底层的网页终端通常只内置了英文字符集，不支持显示中文字符。
解决方法： 放弃网页端，在电脑本地使用专业的 SSH 工具（如 Windows 自带的 CMD、PuTTY 或 Xshell）直接连接服务器 IP，中文就会正常显示。
## 核心笔记二：科学上网的三大核心概念
这三个词构成了你这次“翻墙”的技术全貌：
VLESS（传输协议）： 它是一种极轻量级的数据加密协议。你可以把它理解为一种“高级保密快递打包方式”。它负责把你的网络请求（比如访问 Google）伪装打包，然后安全地发给你的海外服务器。
v2rayN（客户端软件）： 这是运行在你 Windows 电脑上的软件，相当于一个“本地快递驿站”。它的工作就是收发快递——把你的浏览数据用 VLESS 协议打包发出去，并把服务器传回来的数据解包展示给你。
TUN 模式（全局虚拟网卡）： 普通的代理软件只能接管浏览器的流量。而开启 TUN 模式后，v2rayN 会在你电脑底层创建一张“虚拟网卡”。这使得你电脑上所有软件的流量（包括游戏、命令行工具、客户端应用）都会被强制接管并走代理，实现真正的“全局翻墙”。
## 核心笔记三：订阅转换的安全隐患
当你把单行的节点链接（如 vless://...）转换为 Clash 订阅链接（YAML 配置文件）时，需要借助“转换网站”（如 sub.v1.mk）。
风险点： 转换网站的作用是充当“翻译官”和“代写秘书”。为了帮你生成复杂的规则文件，网站后台必须读取并解析你的真实节点密码。
防范建议： 大部分公开的转换站是安全的，但绝对不要随便搜一个不知名的野站去转换，以防你的节点信息被后台偷偷记录并拿去“白嫖”。尽量使用开源项目搭建的知名转换站。
## 核心笔记四：深入理解 SSH（安全外壳协议）
SSH 的全称是 Secure Shell，拆解开来，就是它最核心的两个特性：
1. 为什么叫“安全 (Secure)”？
过去的不安全（Telnet 时代）： 早期远程控制使用的是 Telnet 协议，它的致命伤是明文传输。就像写在明信片上的字，数据从你家到服务器的路上，经过的每个路由器都能直接看到你的账号密码。
现在的安全（SSH 时代）： SSH 引入了非对称加密技术。你敲下的每一次键盘按键，在离开电脑前都会被加密成极度复杂的乱码。哪怕黑客在半路拦截了数据包，没有服务器专属的“私钥”，这堆乱码就绝对无法破解。
2. 为什么叫“外壳 (Shell)”？
内核 (Kernel)： 操作系统的最核心部分，负责直接控制硬件（CPU、内存），但普通用户是无法直接触碰它的。
外壳 (Shell)： 为了让用户能和系统对话，系统在内核外面包了一层“翻译程序”，这就是 Shell。你输入的命令（如 apt-get），就是交给 Shell 翻译给内核去执行的。
终极总结：Secure Shell (SSH) 的意思就是——在你的电脑和远端服务器之间，建立一条极其安全的加密隧道 (Secure)，让你去远程操控服务器的命令行翻译官 (Shell)。
## 一、SSH 安全机制与网络端口号核心总结
首次连接警告（Known Hosts 机制）：提示“The authenticity of host... can't be established”是 SSH 防范中间人劫持攻击的核心手段；服务器会出示专属“指纹”，需输入“yes”确认，指纹会保存至本地 known_hosts 文件，后续若连接假服务器（指纹不匹配），SSH 会拦截风险。
网络端口概念：IP 地址定位服务器（“楼栋”），端口号定位服务器上的特定服务（“房间”）；SSH 默认端口为 22，输入“ssh root@ip”默认连接 22 端口；进阶安全建议：将 22 端口改为冷门端口（如 56789），避开黑客批量扫描破解。
## 二、终端底层编码与 PTY 原理核心总结
TTY 与 PTY 区别：TTY 是服务器上真实的物理显示器和键盘；PTY 是 SSH 远程连接时，服务器内存中虚拟的“显示器和键盘接口”，是本地电脑与服务器系统的通信桥梁。
Windows 终端底层支持：Windows 10 及以上系统，底层 conhost.exe 已重写，支持 VT 序列和原生 UTF-8 渲染，可根据指令动态适配编码。
无乱码通信逻辑链（重点）：① 本地 ssh.exe 连接服务器，申请创建 PTY 并上报本地窗口属性；② 服务器分配 PTY 后，启动 Shell 程序；③ Shell 读取 Linux 系统 UTF-8 环境变量，通过 SSH 告知本地 ssh.exe 后续传输字符为 UTF-8；④ 本地 ssh.exe 强制 CMD 屏蔽默认 GBK，启用 UTF-8 渲染，实现中文正常显示（网页版 VNC 因不支持此协商，故出现乱码）。
## 第一步：申请 PTY（建房间）
你的 ssh.exe 连上服务器后，发起申请：“请给我分配一个 PTY。” 不仅如此，ssh.exe 在申请的同时，还会把你的“本地终端属性”发过去，比如：“我的窗口现在是 120 列宽、30 行高，我支持彩色显示。” (这就好比：你打电话给餐厅，不仅订了一个包厢，还告诉了服务员你来了几个人。)
## 第二步：分配 PTY 并唤醒 Shell（入座）
Linux 服务器收到申请，在内存里划出一块空间，说：“好，PTY 分配完毕。” 紧接着，Linux 会在这个 PTY 里启动一个 Shell（外壳程序，通常是 bash）。也就是你在黑框框里看到带有 root@ubuntu:~# 的那个程序。 (这就好比：包厢准备好了，餐厅大厨（Shell）开始在厨房就位准备为你做菜。)
## 第三步：环境协商与确认（菜单确认，也就是原先的步骤 2）
重点来了！这个 Shell（大厨）被唤醒后，它会去读取 Linux 系统的底层配置文件。它发现 Linux 系统的默认语言环境是 LANG=en_US.UTF-8。
于是，这个运行在 PTY 里的 Shell，会通过 SSH 隧道向你的 Windows ssh.exe 发送一个明确的信号：“哥们，我这边的标准输出全都是 UTF-8 格式的文字哦。”
你的 ssh.exe 收到这个信号，立刻转身对 Windows 的 CMD 窗口下达死命令：“别管你默认的 GBK 了，接下来的所有画面，全部用 UTF-8 给我画出来！”
## Reality技术
Mermaid:
sequenceDiagram
autonumber
actor Client as 你的电脑 (Clash + Chrome)
actor GFW as GFW (审查者/AI流量监控)
participant VPS as 你的云服务器 (Reality)
participant Target as 真实目标 (YouTube)
participant Dest as SNI (伪装目标如微软官网)
Note over Client, Target: 🟢 场景一：非对称加密接力对称加密（安全送达密码本）
Client->>VPS: TCP 三次握手 (修路)
Client->>VPS: TLS Client Hello (明文 SNI: microsoft.com)
Client->>Client: 电脑本地生成极速对称密钥【AES临时密码本】
Client->>VPS: 提交暗号 (ShortId + 用【公钥】锁死的临时密码本)
Note right of VPS: 1. 保安：核对 ShortId 正确！(耗CPU极低)<br/>2. 经理：动用【私钥】解密！(极耗CPU/仅限本次)<br/>3. 成功拿到《AES临时密码本》。经理光荣退场！
VPS->>Client: TLS 握手完成，双方 AES 密码本同步完毕
Note over Client, Target: ⚡ 场景二：Vision 介入与极速传输（对抗 AI 流量特征分析）
Note over Client, VPS: 传统痛点：Clash代理的外层TLS，会把Chrome的内层TLS强行套进去（形成臃肿的 TLS套娃）。<br/>开启 xtls-rprx-vision 流控后：<br/>识别并直接剥离外层代理 TLS，让真实的内层 TLS 裸奔！
Client->>VPS: [彻底抛弃公私钥，仅利用 AES 极速传输 YouTube 数据]
Note left of GFW: GFW AI 启动：持续监控数据包大小、频率、时间间隔...
GFW-->>GFW: 流量特征比对与计算
Note left of GFW: GFW 结论：没有发现“TLS套娃”畸形特征，<br/>包大小完美符合普通的单层 HTTPS。放行！
VPS->>Target: 解开 AES 对称加密，代你向 YouTube 发起真实请求
Target-->>VPS: 返回高清视频数据
VPS-->>Client: [视频流通过单层纯净 TLS (AES) 极速返回客户端]
Note over GFW, Dest: 🔴 场景三：GFW 临时抽查/主动探测（没带暗号）
GFW->>VPS: TCP 三次握手 (修路)
GFW->>VPS: TLS Client Hello (明文 SNI: microsoft.com)
GFW->>VPS: 未带 ShortId / 或者是错误的乱码请求
Note right of VPS: 1. 保安发现 ShortId 不对！<br/>2. 坚决不唤醒经理(不动用私钥)，保护 VPS CPU 不被扫崩！<br/>3. 立刻触发 Reality 终极伪装 (Fallback)
VPS->>Dest: 紧急向真正的微软官网发起连接请求
Dest-->>VPS: 返回最新鲜的、合法的微软 TLS 证书与网页
VPS-->>GFW: 【原封不动透传】真微软的数据给 GFW
Note left of GFW: GFW 验证证书：时间对、签名对。<br/>结论：这真的是个微软海外节点。放行！
TSL:
Xray 配置调优：确保系统稳定运行
1. 核心大动脉：sniffing（流量嗅探）
这是现代代理防封体系的绝对核心，千万不能关。
通俗理解：就像海关的 “X 光安检仪”。
底层原理：当你的加密数据包到达服务器时，Xray 引擎会在不破坏加密内容的前提下，偷偷 “闻一下” 数据包的头部（Header），提取出你要访问的真实目标域名。
为什么必须开启（务必勾选 tls /http）
Vision 引擎的 “眼睛”
xtls-rprx-vision 流控的核心是消除 TLS 套娃特征。关闭嗅探，引擎无法识别 TLS 流量，流量退化、特征暴露，极易被墙。
路由分流的前提
服务器端去广告、国内直连、域名黑名单等规则，都需要通过嗅探获取真实域名。关闭后只能看到 IP，所有高级规则全部失效。
2. 架构级参数：xver（PROXY Protocol Version）
该参数决定节点是单机直连，还是多层中继集群架构。
通俗理解：传递访客真实 IP 的 “接力棒”。
底层原理
前端负载均衡 / 中继服务器 → 后端 X-UI 节点。
未开启 xver 时，后端只能看到前端内网 IP，无法获取用户真实地址，设备限制、IP 审计全部失效。
开启 xver 可实现真实 IP 透传。
本机固定配置：xver = 0
当前架构：客户端直连 VPS，无任何前置中继。
若填写 1 / 2，服务端会强制解析代理协议头，找不到数据直接握手失败、断开连接。单机直连必须设为 0。
3. 极客调试工具：show（Show Reality）
纯开发者调试选项，日常使用必须关闭。
通俗理解：监控 TLS 握手细节的 “显微镜”。
底层原理
开启后，Xray 会在日志完整打印原始 TLS 指纹、Client Hello 及全部调试信息。
适用场景
仅用于：GFW 规则升级、疑似中间人攻击、抓包排错、特征分析。
日常关闭原因
长期开启会疯狂刷写日志，快速占满 VPS 硬盘，引发卡顿、死机、服务崩溃。
4. 终极防线三要素（重中之重）
整套 Reality + Vision 稳定运行的核心硬性规则：
目标域名必须携带 :443
Reality 伪装核心为流量转接。不带 443 可能回落至 80 明文端口，HTTPS 流量伪装逻辑破裂，直接被识别封锁。绑定 443 才能完美匹配大厂加密服务。
ShortId 删掉前方逗号
逗号 = 允许无密钥空连接探测。
删除逗号，启用严格校验，无正确短 ID 的探测包会被直接隔离、转交伪装站，大幅降低主动扫描风险。
彻底弃用旧式 XTLS 开关
旧版 XTLS 存在可被精准识别的漏洞。
现阶段标准方案：Reality 伪装 + xtls-rprx-vision 流控。
1.acceptProxyProtocol (接收代理协议)
它是干嘛的： 你还记得我们之前聊过的那个 xver 吗？xver 是用来让面板记录用户真实 IP 的。而这个 acceptProxyProtocol，就是 Xray 核心用来接收那个真实 IP 数据包的开关。
什么时候开： 只有当你的 X-UI 前面挡了一台 Nginx 或者 HAProxy 负载均衡服务器（集群化运作）时，才需要打开它来接收前端传来的 IP。
为什么你要关： 你是手机/电脑直接连这台 RackNerd 服务器，如果你打开了它，服务器就会傻傻地等一个“代理协议包”，等不到就会直接断开连接。
2. http 伪装 (HTTP 伪装)
它是干嘛的： 这是一个非常古老的技术（在 Shadowsocks 时代很火）。它的作用是硬生生地在你加密的 TCP 数据包前面，塞一段假的 HTTP 网页请求（比如假装自己在看普通的无加密网页）。
为什么你要关： 你现在用的是目前地表最强的 Reality (HTTPS 加密) 伪装！如果你开了这个，就相当于你穿着最先进的隐身衣，却要在头上顶一个大大的“我在看普通网页”的霓虹灯牌。这不仅画蛇添足，而且会让数据包结构变得极其怪异，GFW 一看就会直接把你秒封。
UFW 防火墙操作命令大全
| 类别 | 核心指令代码 | 功能说明 |
| --- | --- | --- |
| 面板控制 (X-UI) | x-ui | 调出系统中文主菜单，修改端口、隐藏路径、升级版本全在这里操作 |
| 面板控制 (X-UI) | x-ui restart | 强制重启面板服务，网页打不开、修改参数未生效时使用 |
| 面板控制 (X-UI) | x-ui status | 查看面板服务存活状态，绿色 active (running) 代表运行正常 |
| 防火墙查询 (UFW) | ufw status numbered | 列出规则并带上编号，增删规则前需先查看当前真实状态 |
| 防火墙查询 (UFW) | ufw reload | 重载防火墙配置，端口规则增删改后必须执行才可生效 |
| 端口放行 (UFW) | ufw allow 443/tcp | 仅放行 443 端口的 TCP 流量，节点配置标准操作 |
| 端口放行 (UFW) | ufw allow 7777 | 放行 7777 端口 TCP+UDP 流量，面板访问常用配置 |
| 规则清理 (UFW) | ufw delete 3 | 精准删除对应编号防火墙规则 |
| 规则清理 (UFW) | ufw delete allow 7777 | 按端口规则名称直接删除放行策略 |
| 规则清理 (UFW) | ufw deny 54321/tcp | 手动指定拦截单个端口流量 |
| 高阶排障 | netstat -tulnp | 查看本机全部开放端口与监听进程 |
| 高阶排障 | lsof -i:443 | 排查指定端口占用，快速定位端口冲突问题 |
1. 为什么 443 端口真的比别的端口保险？（伪装的绝对核心）
答案是：绝对更保险。不仅是保险，在 Reality 和 Vision 协议下，它是“唯一正确的选择”。
GFW 的上帝视角（白名单逻辑）： 现在的 GFW 早就过了逢包必拆的时代，它靠的是大数据统计和异常行为分析。 在正常的互联网世界里，全球 99% 的加密网页流量（HTTPS/TLS）都在跑 443 端口。如果 GFW 看到你的 IP 上，443 端口正源源不断地传输 TLS 加密数据，它的第一反应是：“嗯，这是一个正常的加密网页浏览行为。”
非标端口的“找死”行为： 假设你觉得 443 太显眼，为了“安全”把 Reality 的端口改成了 12345。 GFW 探测机器人一看：“这是啥？一个偏僻的 12345 端口，居然在大流量跑极其复杂的 TLS 1.3 加密数据？正常的业务谁会这么干？” 这种行为在算法眼里叫“特征异常 (Anomaly)”。即使它解不开你的加密包，但它只要觉得你不正常，就可以直接把你掐断（封端口或封 IP）。
总结：伪装的最高境界不是“躲在没人的角落”，而是“混在最拥挤的人群中”。443 就是全网最拥挤的人群。
2. 机场商贩子是怎么做的？他们也只用 443 吗？
这涉及到了翻墙技术的代际演进。机场商贩子的做法已经发生过一次巨大的颠覆：
旧时代（Shadowsocks / SSR 时代）：每人一个端口 以前的机场确实像你猜的那样，利用很多端口。他们会给用户 A 分配 10001，用户 B 分配 10002。因为那个时代的协议很轻量级，机场通过不同的端口来统计谁用了多少流量。 但代价就是：一台服务器上开了几千个乱七八糟的端口，全在往国内发流量。GFW 随便一扫，直接把这台服务器的 IP 给拉黑，这就是为什么以前机场动不动就“全线红掉”。
新时代（V2Ray / Xray / Reality 时代）：单端口，万人骑 现在的顶级机场，全都在用 443 单端口！ 你可能会问：几千个用户全挤在 443 端口，怎么区分张三和李四呢？ 这就是你之前配置过的 UUID 和 SNI（域名识别） 以及 xver（真实IP透传） 发挥作用的时候了。 机场主会在最前面放一台 Nginx（负载均衡器）只监听 443 端口。几千个用户的流量全打进 443 端口，Nginx 就像个前台接待员，通过看你流量里的 UUID 或者域名，再把你精确地分发到背后的各个计费节点上。 这样做的好处： 在 GFW 看来，这台服务器极其“安分守己”，只有一个 443 端口在老老实实地提供正规的 HTTPS 服务，极大地延长了 IP 的寿命。
3. 几千人挤在同一个 443 端口，速度会受限吗？
答案是：绝对不会。多开端口也绝对不会变快。
这里有一个极大的直觉误区：把“端口”当成了物理上的“水管粗细”。 在计算机网络里，端口不是物理管道，而是**“逻辑门牌号”**。
物理带宽才是水管： 决定速度上限的，是你服务器的网卡带宽（比如 1Gbps）和 CPU 处理能力。只要总带宽没跑满，几万人挤一个门牌号也不会慢。
服务器是怎么区分这几千人的？（五元组原理）： 网络底层有一个极其巧妙的设计叫“五元组”。服务器在识别一个连接时，不是只看目标端口（443），而是看五个因素的组合： 源IP + 源端口 + 目标IP + 目标端口(443) + 协议(TCP)。 虽然这几千个用户的目标端口都是 443，但每个用户的“源IP”和他们手机上随机生成的“源端口”全都不一样。 所以，在 Nginx 眼里，这是几千条完全独立、互不干扰的高速通道。这就像一家超级医院（服务器），大门（443端口）只有一个，但里面有几千个医生（线程）在同时接诊，大门本身并不会成为瓶颈。
Xray 核心底层逻辑核心知识点
太棒了！从你提出那个关于“QUIC 为什么不解套”的问题开始，我们的讨论正式进入了现代代理网络协议栈的“深水区”。你敏锐的直觉一步步揭开了 Xray 核心架构中最精妙的攻防设计。
为了方便你日后回顾和作为“节点架构师”的理论储备，我将这段最硬核的底层逻辑为你提炼成以下六个核心知识点：
1. Vision 引擎的“偏科”属性
知识点：xtls-rprx-vision 流控引擎是专一的，它只具备处理 TCP 协议下 TLS 1.3 流量的能力。
现象： 对于基于 UDP 协议的 QUIC 流量，Vision 引擎无法理解，也无法进行“消除套娃（去特征）”的手术。
2. “UDP over TCP”的套娃与伪装
知识点： 当代理软件强行将 QUIC (UDP) 流量通过你的 VLESS (TCP) 节点发送时，会形成“UDP 包装在 TCP 内”的套娃结构。
防封原理： 虽然内部没有被 Vision 解套，但因为最外层有 Reality 协议伪装成了完美的微软 HTTPS 流量，GFW 的审查系统只能看到最外层的合法外壳，因此无法识别并封锁。
3. QUIC 在特殊环境下的“性能灾难”
知识点： 虽然 QUIC（HTTP/3）在理想网络下速度极快，但在跨国翻墙环境中使用它是一场灾难。
两大原因：
协议冲突（堵车）： 将多车道、不可靠的 UDP 强行塞入单车道、要求绝对可靠的 TCP 中，会导致严重的拥塞控制冲突，使得速度断崖式下跌。
UDP QoS 限速： 中国运营商为了限制游戏私服和 P2P 下载，对跨国 UDP 流量实行极其严苛的限速和丢包策略。
4. 终极奥义：“强制降级”与速度之巅
知识点： 代理圈的最佳实践不是去适配 QUIC，而是主动“掐死”它。
运作机制： 高级的客户端分流规则（如你导入的 ACL4SSR 规则）会在本地主动拦截（REJECT）浏览器发出的 QUIC 请求。
精妙结果： 浏览器受挫后，被迫降级为传统的 TCP HTTPS 重新发送请求。这股纯正的 TCP 流量刚好迎合了 Vision 引擎的胃口，被完美解套并丝滑送出国。这种“为了安全而降级”的操作，反而彻底避开了运营商的 UDP 限速，让你跑满物理宽带，实现真正的速度与稳定双赢。
5. Sniffing (嗅探) 与 Routing (路由) 的职能划分
Sniffing（海关 X 光机）： 只负责“看”和“提取”信息（比如提取 SNI 域名），它本身没有任何拦截或修改流量的权利。面板不默认开启 QUIC 嗅探，纯粹是为了节省服务器 CPU 算力。这是经典的性能陷阱，TCP 的重传机制和 QUIC 的多路复用完全冲突，产生 HOL Blocking 的叠加效应，实测掉速非常明显。在国内网络环境下，这是普遍存在的现实，尤其是移动和联通，UDP 流量容易被 traffic shaping。
Routing（海关安保）： 真正执行“放行”、“拦截（REJECT）”或“分流”动作的执行者（依赖于客户端或服务端的规则库）。
6. X-UI 双层架构与重启逻辑
知识点： X-UI 是一套双层系统：上层面板（网页/数据库）+ 底层核心（Xray 发动机）。
操作规范： 在网页端修改 sniffing、端口或用户信息，只是修改了上层的数据库。必须通过网页端的提示弹窗，或者点击“重启 Xray”按钮，让底层发动机重新加载一次配置文件，新规则才会瞬间生效。无需进入 SSH 终端重启整个面板服务。
GFW 封锁机制
## 一、GFW 的工作模型
GFW 不是"发现违规立即惩罚"的实时巡警，而是一套持续运行的统计检测系统：
持续被动采样 → 特征匹配 → 统计置信度积累 → 达到阈值 → 触发封锁
关键含义：
封锁存在滞后性，可能是数小时到数天
同一 IP 可能经历"探测→封锁→解封→再探测"的反复循环
不同省份、不同运营商的 GFW 节点封锁进度不同步
## 二、封锁的触发流程
流量特征触发初步标记（TLS 指纹异常、连接行为异常、流量熵值异常）
GFW 主动探测介入——模拟客户端主动连接目标服务器，试探是否为代理
探测结果暴露代理特征 → IP 进入封锁队列
这正是 VLESS+Reality 等方案的设计目标：让 GFW 的主动探测机器人访问时，只看到正常的 HTTPS 网站响应，无法与真实网站区分。
## 三、封锁维度（并行关系，非递进等级）
GFW 可以在以下任意维度单独出手，也可以多个维度同时叠加。
1. 端口级封锁（TCP RST 注入）
手段：向连接双方同时注入伪造的 TCP RST 包，强制断开指定 IP:Port 的连接
现象：只有目标端口 timeout 或立即 reset，同一 IP 的其他端口正常
验证：telnet <IP> <Port> 或 curl -v，观察是否立即收到 RST
特点：换端口可绕过，是针对非标准端口最常见的初步反应
2. IP 级封锁——单向路由黑洞
手段：GFW 在境内路由层丢弃所有发往该 IP 的数据包
现象：境内无法访问，境外访问完全正常；traceroute 在国内某跳后消失
特点：GFW 只控制入境流量，封锁是单向的
3. IP 级封锁——双向 Null Route
手段：全局路由黑洞，所有方向均不通
现象：境内境外均无法访问
恢复：必须更换 IP
4. TCP 层冻结（SYN 过滤）
手段：过滤 TCP SYN 包（连接建立阶段），ICMP 不受影响
现象：ping 有回应，但 SSH、HTTP、代理等所有 TCP 连接全部 timeout
特点：常见于临时性封锁或 GFW 主动探测阶段，通常不是永久状态
5. DNS 污染
手段：劫持境内 DNS 查询，对目标域名返回虚假 IP
现象：域名解析到错误地址，直接用 IP 访问不受影响
特点：与 IP 封锁完全独立，可单独存在，也可同时叠加
绕过：使用境外 DNS（DoH/DoT）或直接 IP 连接
## 四、各维度对比速查
| 封锁维度 | 技术手段 | 可观测现象 | 绕过思路 |
| --- | --- | --- | --- |
| 端口级 | TCP RST 注入 | 特定端口断开，其余正常 | 更换端口 |
| IP 级（单向） | 境内路由黑洞 | 境内不通，境外正常 | 更换 IP |
| IP 级（双向） | 全局 Null Route | 所有方向均不通 | 更换 IP |
| TCP 层冻结 | SYN 包过滤 | ping 通但 TCP 全不通 | 等待解封或换 IP |
| DNS 污染 | 查询劫持 | 域名解析错误 | 境外 DNS / IP 直连 |
防火长城：为什么你的墙和别人的墙不一样
一句话核心
GFW 不是一堵墙，是一套分布式审查流水线——国家出策略，地方管执行，三大运营商各走各路。
架构本质：集中下令 × 分散执行
国家级指令
│
▼
北上广 国际出口网关 ← 核心封锁层
│
▼
省级 / 市级骨干节点 ← 二级执行层（设备型号/固件各异）
│
▼
电信 / 联通 / 移动 / CERNET ← 各 ISP 独立路由
关键问题： 各层设备的更新频率不同 → 同一份黑名单，各地执行时间不同步。
为什么你能访问，我却不行？
| 差异维度 | 具体原因 |
| --- | --- |
| 运营商路由 | 电信走太平洋直连，移动走 CMI，同一 IP 走不同海缆，封锁节点不同 |
| DPI 策略 | 各 ISP 部署的深度包检测规则不完全一致，某些协议在联通被拦，移动照过 |
| 省级独立黑名单 | 各地反诈中心 / 通信管理局可自行在省级 DNS 或网关追加封锁 |
| 高压地区例外 | 新疆、西藏近似白名单机制，规则完全独立于内地省份 |
"间歇性解封"的真相
不是真的解封，是同步延迟 + 配置漏洞。
DNS 污染撤销 → 需要逐级缓存刷新，全国同步可能需要数小时至数天
设备故障 / 规则未推送 → 某运营商某省节点漏封
结果：A 省电信能开，B 省移动打不开 —— 同一网站，体感完全不同
一句话总结各层逻辑
| 层级 | 谁来决定 | 决定什么 |
| --- | --- | --- |
| 国家 | 网信办 / 公安部 | 顶级黑名单（Google、YouTube 等） |
| 运营商 | 电信 / 联通 / 移动 | 路由路径、DPI 规则、协议过滤力度 |
| 省级 | 地方通管局 / 反诈中心 | 区域性追加封锁 |
| 设备 | 各节点硬件 | 执行时效、更新延迟 |
你体感到的"墙"= 以上四层叠加的交集，所以每个人的墙细节上都不一样。
| 你的困境 | 背后原因 | 应对思路 |
| --- | --- | --- |
| VPS 突然连不上 | 电信某出口节点新增封锁 | 换移动热点试试路由 |
| 朋友能用你不能用 | ISP 的 DPI 规则不同步 | 换运营商或换协议 |
| 某省打不开某省能开 | 地方通管局独立黑名单 | 换省级出口或用 DNS-over-HTTPS |
| 间歇性神奇可访问 | 节点缓存空窗期 | 不稳定，别依赖 |
| 出差新疆全部失效 | 白名单机制，规则体系不同 | 提前准备，出发前配置好 |
| 校园网体验更好 | CERNET 学术豁免 | 合理利用校园网出口 |
| TCP 死 UDP 活 | DPI 对协议特征识别精度不同 | 优先选 UDP 协议工具 |
服务器与网络核心概念笔记
## 核心笔记一：X-UI 终端乱码的真相
X-UI 安装脚本使用的是标准的 UTF-8 中文编码，本身没有任何问题。
乱码的原因在于“显示器”不对： 你当时使用的是服务商（SolusVM 控制面板）自带的网页版 VNC 终端。这种底层的网页终端通常只内置了英文字符集，不支持显示中文字符。
解决方法： 放弃网页端，在电脑本地使用专业的 SSH 工具（如 Windows 自带的 CMD、PuTTY 或 Xshell）直接连接服务器 IP，中文就会正常显示。
## 核心笔记二：科学上网的三大核心概念
这三个词构成了你这次“翻墙”的技术全貌：
VLESS（传输协议）： 它是一种极轻量级的数据加密协议。你可以把它理解为一种“高级保密快递打包方式”。它负责把你的网络请求（比如访问 Google）伪装打包，然后安全地发给你的海外服务器。
v2rayN（客户端软件）： 这是运行在你 Windows 电脑上的软件，相当于一个“本地快递驿站”。它的工作就是收发快递——把你的浏览数据用 VLESS 协议打包发出去，并把服务器传回来的数据解包展示给你。
TUN 模式（全局虚拟网卡）： 普通的代理软件只能接管浏览器的流量。而开启 TUN 模式后，v2rayN 会在你电脑底层创建一张“虚拟网卡”。这使得你电脑上所有软件的流量（包括游戏、命令行工具、客户端应用）都会被强制接管并走代理，实现真正的“全局翻墙”。
## 核心笔记三：订阅转换的安全隐患
当你把单行的节点链接（如 vless://...）转换为 Clash 订阅链接（YAML 配置文件）时，需要借助“转换网站”（如 sub.v1.mk）。
风险点： 转换网站的作用是充当“翻译官”和“代写秘书”。为了帮你生成复杂的规则文件，网站后台必须读取并解析你的真实节点密码。
防范建议： 大部分公开的转换站是安全的，但绝对不要随便搜一个不知名的野站去转换，以防你的节点信息被后台偷偷记录并拿去“白嫖”。尽量使用开源项目搭建的知名转换站。
## 核心笔记四：深入理解 SSH（安全外壳协议）
SSH 的全称是 Secure Shell，拆解开来，就是它最核心的两个特性：
1. 为什么叫“安全 (Secure)”？
过去的不安全（Telnet 时代）： 早期远程控制使用的是 Telnet 协议，它的致命伤是明文传输。就像写在明信片上的字，数据从你家到服务器的路上，经过的每个路由器都能直接看到你的账号密码。
现在的安全（SSH 时代）： SSH 引入了非对称加密技术。你敲下的每一次键盘按键，在离开电脑前都会被加密成极度复杂的乱码。哪怕黑客在半路拦截了数据包，没有服务器专属的“私钥”，这堆乱码就绝对无法破解。
2. 为什么叫“外壳 (Shell)”？
内核 (Kernel)： 操作系统的最核心部分，负责直接控制硬件（CPU、内存），但普通用户是无法直接触碰它的。
外壳 (Shell)： 为了让用户能和系统对话，系统在内核外面包了一层“翻译程序”，这就是 Shell。你输入的命令（如 apt-get），就是交给 Shell 翻译给内核去执行的。
终极总结：Secure Shell (SSH) 的意思就是——在你的电脑和远端服务器之间，建立一条极其安全的加密隧道 (Secure)，让你去远程操控服务器的命令行翻译官 (Shell)。
## 一、SSH 安全机制与网络端口号核心总结
首次连接警告（Known Hosts 机制）：提示“The authenticity of host... can't be established”是 SSH 防范中间人劫持攻击的核心手段；服务器会出示专属“指纹”，需输入“yes”确认，指纹会保存至本地 known_hosts 文件，后续若连接假服务器（指纹不匹配），SSH 会拦截风险。
网络端口概念：IP 地址定位服务器（“楼栋”），端口号定位服务器上的特定服务（“房间”）；SSH 默认端口为 22，输入“ssh root@ip”默认连接 22 端口；进阶安全建议：将 22 端口改为冷门端口（如 56789），避开黑客批量扫描破解。
## 二、终端底层编码与 PTY 原理核心总结
TTY 与 PTY 区别：TTY 是服务器上真实的物理显示器和键盘；PTY 是 SSH 远程连接时，服务器内存中虚拟的“显示器和键盘接口”，是本地电脑与服务器系统的通信桥梁。
Windows 终端底层支持：Windows 10 及以上系统，底层 conhost.exe 已重写，支持 VT 序列和原生 UTF-8 渲染，可根据指令动态适配编码。
无乱码通信逻辑链（重点）：① 本地 ssh.exe 连接服务器，申请创建 PTY 并上报本地窗口属性；② 服务器分配 PTY 后，启动 Shell 程序；③ Shell 读取 Linux 系统 UTF-8 环境变量，通过 SSH 告知本地 ssh.exe 后续传输字符为 UTF-8；④ 本地 ssh.exe 强制 CMD 屏蔽默认 GBK，启用 UTF-8 渲染，实现中文正常显示（网页版 VNC 因不支持此协商，故出现乱码）。
## 第一步：申请 PTY（建房间）
你的 ssh.exe 连上服务器后，发起申请：“请给我分配一个 PTY。” 不仅如此，ssh.exe 在申请的同时，还会把你的“本地终端属性”发过去，比如：“我的窗口现在是 120 列宽、30 行高，我支持彩色显示。” (这就好比：你打电话给餐厅，不仅订了一个包厢，还告诉了服务员你来了几个人。)
## 第二步：分配 PTY 并唤醒 Shell（入座）
Linux 服务器收到申请，在内存里划出一块空间，说：“好，PTY 分配完毕。” 紧接着，Linux 会在这个 PTY 里启动一个 Shell（外壳程序，通常是 bash）。也就是你在黑框框里看到带有 root@ubuntu:~# 的那个程序。 (这就好比：包厢准备好了，餐厅大厨（Shell）开始在厨房就位准备为你做菜。)
## 第三步：环境协商与确认（菜单确认，也就是原先的步骤 2）
重点来了！这个 Shell（大厨）被唤醒后，它会去读取 Linux 系统的底层配置文件。它发现 Linux 系统的默认语言环境是 LANG=en_US.UTF-8。
于是，这个运行在 PTY 里的 Shell，会通过 SSH 隧道向你的 Windows ssh.exe 发送一个明确的信号：“哥们，我这边的标准输出全都是 UTF-8 格式的文字哦。”
你的 ssh.exe 收到这个信号，立刻转身对 Windows 的 CMD 窗口下达死命令：“别管你默认的 GBK 了，接下来的所有画面，全部用 UTF-8 给我画出来！”
## Reality技术
Mermaid:
sequenceDiagram
autonumber
actor Client as 你的电脑 (Clash + Chrome)
actor GFW as GFW (审查者/AI流量监控)
participant VPS as 你的云服务器 (Reality)
participant Target as 真实目标 (YouTube)
participant Dest as SNI (伪装目标如微软官网)
Note over Client, Target: 🟢 场景一：非对称加密接力对称加密（安全送达密码本）
Client->>VPS: TCP 三次握手 (修路)
Client->>VPS: TLS Client Hello (明文 SNI: microsoft.com)
Client->>Client: 电脑本地生成极速对称密钥【AES临时密码本】
Client->>VPS: 提交暗号 (ShortId + 用【公钥】锁死的临时密码本)
Note right of VPS: 1. 保安：核对 ShortId 正确！(耗CPU极低)<br/>2. 经理：动用【私钥】解密！(极耗CPU/仅限本次)<br/>3. 成功拿到《AES临时密码本》。经理光荣退场！
VPS->>Client: TLS 握手完成，双方 AES 密码本同步完毕
Note over Client, Target: ⚡ 场景二：Vision 介入与极速传输（对抗 AI 流量特征分析）
Note over Client, VPS: 传统痛点：Clash代理的外层TLS，会把Chrome的内层TLS强行套进去（形成臃肿的 TLS套娃）。<br/>开启 xtls-rprx-vision 流控后：<br/>识别并直接剥离外层代理 TLS，让真实的内层 TLS 裸奔！
Client->>VPS: [彻底抛弃公私钥，仅利用 AES 极速传输 YouTube 数据]
Note left of GFW: GFW AI 启动：持续监控数据包大小、频率、时间间隔...
GFW-->>GFW: 流量特征比对与计算
Note left of GFW: GFW 结论：没有发现“TLS套娃”畸形特征，<br/>包大小完美符合普通的单层 HTTPS。放行！
VPS->>Target: 解开 AES 对称加密，代你向 YouTube 发起真实请求
Target-->>VPS: 返回高清视频数据
VPS-->>Client: [视频流通过单层纯净 TLS (AES) 极速返回客户端]
Note over GFW, Dest: 🔴 场景三：GFW 临时抽查/主动探测（没带暗号）
GFW->>VPS: TCP 三次握手 (修路)
GFW->>VPS: TLS Client Hello (明文 SNI: microsoft.com)
GFW->>VPS: 未带 ShortId / 或者是错误的乱码请求
Note right of VPS: 1. 保安发现 ShortId 不对！<br/>2. 坚决不唤醒经理(不动用私钥)，保护 VPS CPU 不被扫崩！<br/>3. 立刻触发 Reality 终极伪装 (Fallback)
VPS->>Dest: 紧急向真正的微软官网发起连接请求
Dest-->>VPS: 返回最新鲜的、合法的微软 TLS 证书与网页
VPS-->>GFW: 【原封不动透传】真微软的数据给 GFW
Note left of GFW: GFW 验证证书：时间对、签名对。<br/>结论：这真的是个微软海外节点。放行！
TSL:
Xray 配置调优：确保系统稳定运行
1. 核心大动脉：sniffing（流量嗅探）
这是现代代理防封体系的绝对核心，千万不能关。
通俗理解：就像海关的 “X 光安检仪”。
底层原理：当你的加密数据包到达服务器时，Xray 引擎会在不破坏加密内容的前提下，偷偷 “闻一下” 数据包的头部（Header），提取出你要访问的真实目标域名。
为什么必须开启（务必勾选 tls /http）
Vision 引擎的 “眼睛”
xtls-rprx-vision 流控的核心是消除 TLS 套娃特征。关闭嗅探，引擎无法识别 TLS 流量，流量退化、特征暴露，极易被墙。
路由分流的前提
服务器端去广告、国内直连、域名黑名单等规则，都需要通过嗅探获取真实域名。关闭后只能看到 IP，所有高级规则全部失效。
2. 架构级参数：xver（PROXY Protocol Version）
该参数决定节点是单机直连，还是多层中继集群架构。
通俗理解：传递访客真实 IP 的 “接力棒”。
底层原理
前端负载均衡 / 中继服务器 → 后端 X-UI 节点。
未开启 xver 时，后端只能看到前端内网 IP，无法获取用户真实地址，设备限制、IP 审计全部失效。
开启 xver 可实现真实 IP 透传。
本机固定配置：xver = 0
当前架构：客户端直连 VPS，无任何前置中继。
若填写 1 / 2，服务端会强制解析代理协议头，找不到数据直接握手失败、断开连接。单机直连必须设为 0。
3. 极客调试工具：show（Show Reality）
纯开发者调试选项，日常使用必须关闭。
通俗理解：监控 TLS 握手细节的 “显微镜”。
底层原理
开启后，Xray 会在日志完整打印原始 TLS 指纹、Client Hello 及全部调试信息。
适用场景
仅用于：GFW 规则升级、疑似中间人攻击、抓包排错、特征分析。
日常关闭原因
长期开启会疯狂刷写日志，快速占满 VPS 硬盘，引发卡顿、死机、服务崩溃。
4. 终极防线三要素（重中之重）
整套 Reality + Vision 稳定运行的核心硬性规则：
目标域名必须携带 :443
Reality 伪装核心为流量转接。不带 443 可能回落至 80 明文端口，HTTPS 流量伪装逻辑破裂，直接被识别封锁。绑定 443 才能完美匹配大厂加密服务。
ShortId 删掉前方逗号
逗号 = 允许无密钥空连接探测。
删除逗号，启用严格校验，无正确短 ID 的探测包会被直接隔离、转交伪装站，大幅降低主动扫描风险。
彻底弃用旧式 XTLS 开关
旧版 XTLS 存在可被精准识别的漏洞。
现阶段标准方案：Reality 伪装 + xtls-rprx-vision 流控。
1.acceptProxyProtocol (接收代理协议)
它是干嘛的： 你还记得我们之前聊过的那个 xver 吗？xver 是用来让面板记录用户真实 IP 的。而这个 acceptProxyProtocol，就是 Xray 核心用来接收那个真实 IP 数据包的开关。
什么时候开： 只有当你的 X-UI 前面挡了一台 Nginx 或者 HAProxy 负载均衡服务器（集群化运作）时，才需要打开它来接收前端传来的 IP。
为什么你要关： 你是手机/电脑直接连这台 RackNerd 服务器，如果你打开了它，服务器就会傻傻地等一个“代理协议包”，等不到就会直接断开连接。
2. http 伪装 (HTTP 伪装)
它是干嘛的： 这是一个非常古老的技术（在 Shadowsocks 时代很火）。它的作用是硬生生地在你加密的 TCP 数据包前面，塞一段假的 HTTP 网页请求（比如假装自己在看普通的无加密网页）。
为什么你要关： 你现在用的是目前地表最强的 Reality (HTTPS 加密) 伪装！如果你开了这个，就相当于你穿着最先进的隐身衣，却要在头上顶一个大大的“我在看普通网页”的霓虹灯牌。这不仅画蛇添足，而且会让数据包结构变得极其怪异，GFW 一看就会直接把你秒封。
UFW 防火墙操作命令大全
| 类别 | 核心指令代码 | 功能说明 |
| --- | --- | --- |
| 面板控制 (X-UI) | x-ui | 调出系统中文主菜单，修改端口、隐藏路径、升级版本全在这里操作 |
| 面板控制 (X-UI) | x-ui restart | 强制重启面板服务，网页打不开、修改参数未生效时使用 |
| 面板控制 (X-UI) | x-ui status | 查看面板服务存活状态，绿色 active (running) 代表运行正常 |
| 防火墙查询 (UFW) | ufw status numbered | 列出规则并带上编号，增删规则前需先查看当前真实状态 |
| 防火墙查询 (UFW) | ufw reload | 重载防火墙配置，端口规则增删改后必须执行才可生效 |
| 端口放行 (UFW) | ufw allow 443/tcp | 仅放行 443 端口的 TCP 流量，节点配置标准操作 |
| 端口放行 (UFW) | ufw allow 7777 | 放行 7777 端口 TCP+UDP 流量，面板访问常用配置 |
| 规则清理 (UFW) | ufw delete 3 | 精准删除对应编号防火墙规则 |
| 规则清理 (UFW) | ufw delete allow 7777 | 按端口规则名称直接删除放行策略 |
| 规则清理 (UFW) | ufw deny 54321/tcp | 手动指定拦截单个端口流量 |
| 高阶排障 | netstat -tulnp | 查看本机全部开放端口与监听进程 |
| 高阶排障 | lsof -i:443 | 排查指定端口占用，快速定位端口冲突问题 |
1. 为什么 443 端口真的比别的端口保险？（伪装的绝对核心）
答案是：绝对更保险。不仅是保险，在 Reality 和 Vision 协议下，它是“唯一正确的选择”。
GFW 的上帝视角（白名单逻辑）： 现在的 GFW 早就过了逢包必拆的时代，它靠的是大数据统计和异常行为分析。 在正常的互联网世界里，全球 99% 的加密网页流量（HTTPS/TLS）都在跑 443 端口。如果 GFW 看到你的 IP 上，443 端口正源源不断地传输 TLS 加密数据，它的第一反应是：“嗯，这是一个正常的加密网页浏览行为。”
非标端口的“找死”行为： 假设你觉得 443 太显眼，为了“安全”把 Reality 的端口改成了 12345。 GFW 探测机器人一看：“这是啥？一个偏僻的 12345 端口，居然在大流量跑极其复杂的 TLS 1.3 加密数据？正常的业务谁会这么干？” 这种行为在算法眼里叫“特征异常 (Anomaly)”。即使它解不开你的加密包，但它只要觉得你不正常，就可以直接把你掐断（封端口或封 IP）。
总结：伪装的最高境界不是“躲在没人的角落”，而是“混在最拥挤的人群中”。443 就是全网最拥挤的人群。
2. 机场商贩子是怎么做的？他们也只用 443 吗？
这涉及到了翻墙技术的代际演进。机场商贩子的做法已经发生过一次巨大的颠覆：
旧时代（Shadowsocks / SSR 时代）：每人一个端口 以前的机场确实像你猜的那样，利用很多端口。他们会给用户 A 分配 10001，用户 B 分配 10002。因为那个时代的协议很轻量级，机场通过不同的端口来统计谁用了多少流量。 但代价就是：一台服务器上开了几千个乱七八糟的端口，全在往国内发流量。GFW 随便一扫，直接把这台服务器的 IP 给拉黑，这就是为什么以前机场动不动就“全线红掉”。
新时代（V2Ray / Xray / Reality 时代）：单端口，万人骑 现在的顶级机场，全都在用 443 单端口！ 你可能会问：几千个用户全挤在 443 端口，怎么区分张三和李四呢？ 这就是你之前配置过的 UUID 和 SNI（域名识别） 以及 xver（真实IP透传） 发挥作用的时候了。 机场主会在最前面放一台 Nginx（负载均衡器）只监听 443 端口。几千个用户的流量全打进 443 端口，Nginx 就像个前台接待员，通过看你流量里的 UUID 或者域名，再把你精确地分发到背后的各个计费节点上。 这样做的好处： 在 GFW 看来，这台服务器极其“安分守己”，只有一个 443 端口在老老实实地提供正规的 HTTPS 服务，极大地延长了 IP 的寿命。
3. 几千人挤在同一个 443 端口，速度会受限吗？
答案是：绝对不会。多开端口也绝对不会变快。
这里有一个极大的直觉误区：把“端口”当成了物理上的“水管粗细”。 在计算机网络里，端口不是物理管道，而是**“逻辑门牌号”**。
物理带宽才是水管： 决定速度上限的，是你服务器的网卡带宽（比如 1Gbps）和 CPU 处理能力。只要总带宽没跑满，几万人挤一个门牌号也不会慢。
服务器是怎么区分这几千人的？（五元组原理）： 网络底层有一个极其巧妙的设计叫“五元组”。服务器在识别一个连接时，不是只看目标端口（443），而是看五个因素的组合： 源IP + 源端口 + 目标IP + 目标端口(443) + 协议(TCP)。 虽然这几千个用户的目标端口都是 443，但每个用户的“源IP”和他们手机上随机生成的“源端口”全都不一样。 所以，在 Nginx 眼里，这是几千条完全独立、互不干扰的高速通道。这就像一家超级医院（服务器），大门（443端口）只有一个，但里面有几千个医生（线程）在同时接诊，大门本身并不会成为瓶颈。
Xray 核心底层逻辑核心知识点
太棒了！从你提出那个关于“QUIC 为什么不解套”的问题开始，我们的讨论正式进入了现代代理网络协议栈的“深水区”。你敏锐的直觉一步步揭开了 Xray 核心架构中最精妙的攻防设计。
为了方便你日后回顾和作为“节点架构师”的理论储备，我将这段最硬核的底层逻辑为你提炼成以下六个核心知识点：
1. Vision 引擎的“偏科”属性
知识点：xtls-rprx-vision 流控引擎是专一的，它只具备处理 TCP 协议下 TLS 1.3 流量的能力。
现象： 对于基于 UDP 协议的 QUIC 流量，Vision 引擎无法理解，也无法进行“消除套娃（去特征）”的手术。
2. “UDP over TCP”的套娃与伪装
知识点： 当代理软件强行将 QUIC (UDP) 流量通过你的 VLESS (TCP) 节点发送时，会形成“UDP 包装在 TCP 内”的套娃结构。
防封原理： 虽然内部没有被 Vision 解套，但因为最外层有 Reality 协议伪装成了完美的微软 HTTPS 流量，GFW 的审查系统只能看到最外层的合法外壳，因此无法识别并封锁。
3. QUIC 在特殊环境下的“性能灾难”
知识点： 虽然 QUIC（HTTP/3）在理想网络下速度极快，但在跨国翻墙环境中使用它是一场灾难。
两大原因：
协议冲突（堵车）： 将多车道、不可靠的 UDP 强行塞入单车道、要求绝对可靠的 TCP 中，会导致严重的拥塞控制冲突，使得速度断崖式下跌。
UDP QoS 限速： 中国运营商为了限制游戏私服和 P2P 下载，对跨国 UDP 流量实行极其严苛的限速和丢包策略。
4. 终极奥义：“强制降级”与速度之巅
知识点： 代理圈的最佳实践不是去适配 QUIC，而是主动“掐死”它。
运作机制： 高级的客户端分流规则（如你导入的 ACL4SSR 规则）会在本地主动拦截（REJECT）浏览器发出的 QUIC 请求。
精妙结果： 浏览器受挫后，被迫降级为传统的 TCP HTTPS 重新发送请求。这股纯正的 TCP 流量刚好迎合了 Vision 引擎的胃口，被完美解套并丝滑送出国。这种“为了安全而降级”的操作，反而彻底避开了运营商的 UDP 限速，让你跑满物理宽带，实现真正的速度与稳定双赢。
5. Sniffing (嗅探) 与 Routing (路由) 的职能划分
Sniffing（海关 X 光机）： 只负责“看”和“提取”信息（比如提取 SNI 域名），它本身没有任何拦截或修改流量的权利。面板不默认开启 QUIC 嗅探，纯粹是为了节省服务器 CPU 算力。这是经典的性能陷阱，TCP 的重传机制和 QUIC 的多路复用完全冲突，产生 HOL Blocking 的叠加效应，实测掉速非常明显。在国内网络环境下，这是普遍存在的现实，尤其是移动和联通，UDP 流量容易被 traffic shaping。
Routing（海关安保）： 真正执行“放行”、“拦截（REJECT）”或“分流”动作的执行者（依赖于客户端或服务端的规则库）。
6. X-UI 双层架构与重启逻辑
知识点： X-UI 是一套双层系统：上层面板（网页/数据库）+ 底层核心（Xray 发动机）。
操作规范： 在网页端修改 sniffing、端口或用户信息，只是修改了上层的数据库。必须通过网页端的提示弹窗，或者点击“重启 Xray”按钮，让底层发动机重新加载一次配置文件，新规则才会瞬间生效。无需进入 SSH 终端重启整个面板服务。
GFW 封锁机制
## 一、GFW 的工作模型
GFW 不是"发现违规立即惩罚"的实时巡警，而是一套持续运行的统计检测系统：
持续被动采样 → 特征匹配 → 统计置信度积累 → 达到阈值 → 触发封锁
关键含义：
封锁存在滞后性，可能是数小时到数天
同一 IP 可能经历"探测→封锁→解封→再探测"的反复循环
不同省份、不同运营商的 GFW 节点封锁进度不同步
## 二、封锁的触发流程
流量特征触发初步标记（TLS 指纹异常、连接行为异常、流量熵值异常）
GFW 主动探测介入——模拟客户端主动连接目标服务器，试探是否为代理
探测结果暴露代理特征 → IP 进入封锁队列
这正是 VLESS+Reality 等方案的设计目标：让 GFW 的主动探测机器人访问时，只看到正常的 HTTPS 网站响应，无法与真实网站区分。
## 三、封锁维度（并行关系，非递进等级）
GFW 可以在以下任意维度单独出手，也可以多个维度同时叠加。
1. 端口级封锁（TCP RST 注入）
手段：向连接双方同时注入伪造的 TCP RST 包，强制断开指定 IP:Port 的连接
现象：只有目标端口 timeout 或立即 reset，同一 IP 的其他端口正常
验证：telnet <IP> <Port> 或 curl -v，观察是否立即收到 RST
特点：换端口可绕过，是针对非标准端口最常见的初步反应
2. IP 级封锁——单向路由黑洞
手段：GFW 在境内路由层丢弃所有发往该 IP 的数据包
现象：境内无法访问，境外访问完全正常；traceroute 在国内某跳后消失
特点：GFW 只控制入境流量，封锁是单向的
3. IP 级封锁——双向 Null Route
手段：全局路由黑洞，所有方向均不通
现象：境内境外均无法访问
恢复：必须更换 IP
4. TCP 层冻结（SYN 过滤）
手段：过滤 TCP SYN 包（连接建立阶段），ICMP 不受影响
现象：ping 有回应，但 SSH、HTTP、代理等所有 TCP 连接全部 timeout
特点：常见于临时性封锁或 GFW 主动探测阶段，通常不是永久状态
5. DNS 污染
手段：劫持境内 DNS 查询，对目标域名返回虚假 IP
现象：域名解析到错误地址，直接用 IP 访问不受影响
特点：与 IP 封锁完全独立，可单独存在，也可同时叠加
绕过：使用境外 DNS（DoH/DoT）或直接 IP 连接
## 四、各维度对比速查
| 封锁维度 | 技术手段 | 可观测现象 | 绕过思路 |
| --- | --- | --- | --- |
| 端口级 | TCP RST 注入 | 特定端口断开，其余正常 | 更换端口 |
| IP 级（单向） | 境内路由黑洞 | 境内不通，境外正常 | 更换 IP |
| IP 级（双向） | 全局 Null Route | 所有方向均不通 | 更换 IP |
| TCP 层冻结 | SYN 包过滤 | ping 通但 TCP 全不通 | 等待解封或换 IP |
| DNS 污染 | 查询劫持 | 域名解析错误 | 境外 DNS / IP 直连 |
防火长城：为什么你的墙和别人的墙不一样
一句话核心
GFW 不是一堵墙，是一套分布式审查流水线——国家出策略，地方管执行，三大运营商各走各路。
架构本质：集中下令 × 分散执行
国家级指令
│
▼
北上广 国际出口网关 ← 核心封锁层
│
▼
省级 / 市级骨干节点 ← 二级执行层（设备型号/固件各异）
│
▼
电信 / 联通 / 移动 / CERNET ← 各 ISP 独立路由
关键问题： 各层设备的更新频率不同 → 同一份黑名单，各地执行时间不同步。
为什么你能访问，我却不行？
| 差异维度 | 具体原因 |
| --- | --- |
| 运营商路由 | 电信走太平洋直连，移动走 CMI，同一 IP 走不同海缆，封锁节点不同 |
| DPI 策略 | 各 ISP 部署的深度包检测规则不完全一致，某些协议在联通被拦，移动照过 |
| 省级独立黑名单 | 各地反诈中心 / 通信管理局可自行在省级 DNS 或网关追加封锁 |
| 高压地区例外 | 新疆、西藏近似白名单机制，规则完全独立于内地省份 |
"间歇性解封"的真相
不是真的解封，是同步延迟 + 配置漏洞。
DNS 污染撤销 → 需要逐级缓存刷新，全国同步可能需要数小时至数天
设备故障 / 规则未推送 → 某运营商某省节点漏封
结果：A 省电信能开，B 省移动打不开 —— 同一网站，体感完全不同
一句话总结各层逻辑
| 层级 | 谁来决定 | 决定什么 |
| --- | --- | --- |
| 国家 | 网信办 / 公安部 | 顶级黑名单（Google、YouTube 等） |
| 运营商 | 电信 / 联通 / 移动 | 路由路径、DPI 规则、协议过滤力度 |
| 省级 | 地方通管局 / 反诈中心 | 区域性追加封锁 |
| 设备 | 各节点硬件 | 执行时效、更新延迟 |
你体感到的"墙"= 以上四层叠加的交集，所以每个人的墙细节上都不一样。
| 你的困境 | 背后原因 | 应对思路 |
| --- | --- | --- |
| VPS 突然连不上 | 电信某出口节点新增封锁 | 换移动热点试试路由 |
| 朋友能用你不能用 | ISP 的 DPI 规则不同步 | 换运营商或换协议 |
| 某省打不开某省能开 | 地方通管局独立黑名单 | 换省级出口或用 DNS-over-HTTPS |
| 间歇性神奇可访问 | 节点缓存空窗期 | 不稳定，别依赖 |
| 出差新疆全部失效 | 白名单机制，规则体系不同 | 提前准备，出发前配置好 |
| 校园网体验更好 | CERNET 学术豁免 | 合理利用校园网出口 |
| TCP 死 UDP 活 | DPI 对协议特征识别精度不同 | 优先选 UDP 协议工具 |