切换主题

NAT VPS 自建代理的原理 ​

2026-09-20 20:07:14

https://x.com/mjjwiki/status/2100453699659366890

先讲小白版(前端类比),技术细节在后。

一句话:全局版的 dev proxy ​

你肯定在 vite.config.ts 里写过这个:

ts
server: {
  proxy: { '/api': 'https://后端服务器.com' }
}

浏览器以为自己在请求本地 /api,其实是 vite 替你把请求转给了真实后端,再把结果带回来。

翻墙的本质就是这件事:设备上跑一个代理程序(Clash),浏览器把请求交给它,它替你访问目标网站,拿到结果再还给你。唯一的区别是——这个"替你跑腿的人"身在新加坡。

各角色是什么(前端类比) ​

  • VPS = 一台放在新加坡机房、24 小时开机的电脑。它上网没有限制,"翻墙" = 借它的身份上网。
  • NAT VPS = 这台电脑是合租的。独立 VPS 像整租(独占门牌号 = 公网 IP),$5/月;NAT VPS 十几人合租(共享一个门牌号),所以 2 元/月。代价:快递没法直接寄到你家,只能寄到小区收发室,房东按编号分发——这就是端口转发(外部端口 34438 → 你家插座 2081),外人只能敲 34438,看不到 2081。
  • Xray = 跑在 VPS 上的核心程序,角色类似 nginx:监听端口、按配置处理连接。
  • 3x-ui = xray 的宝塔面板。xray 只认一份 config.json,3x-ui 给你个网页点点点,最后还是改那份 json。"搭建 3x-ui" 翻译过来就是:装了个有图形界面的 nginx。

完整走一遍:访问 Google 时发生了什么 ​

  1. 浏览器把请求交给本机 Clash(127.0.0.1:7897)
  2. Clash 查规则表——一串 if-else,类似 nginx 的 location 匹配:google.com 命中国外 → 走隧道;bilibili.com → 直连
  3. Clash 把"我要访问 google"加密打包,伪装成一段访问 apple.com 的 HTTPS 流量,发往 VPS 的 34438 端口
  4. VPS 上的 Xray 验暗号通过,拆包,以自己的身份请求 Google(新加坡畅通无阻)
  5. 结果原路加密送回,Clash 拆包交给浏览器

全程墙只看到:你和某个 IP 之间有一堆"和苹果网站的正常 HTTPS 通信"。

REALITY 为什么能抗封锁 ​

背景:正常 HTTPS 流量,墙能看懂"信封"——能看到你要访问 www.apple.com(SNI)和苹果的真证书,只是看不到信里的内容。墙不能封 HTTPS(等于封掉半个互联网),所以代理要活下来,就得长得和普通 HTTPS 一模一样。

REALITY 像一家暗店(speakeasy):

  • 门面是货真价实的苹果网站。任何人来访问——包括墙派来的稽查员——看到的都是真 apple.com:真证书、真页面,零破绽
  • 客户端和服务器在 TLS 握手时用密钥交换悄悄对暗号(配置里的 pbk、sid 就是暗号本),对上了,这条连接才变成代理隧道
  • 所以墙来探测节点,结果就是"访问了一个苹果网站",和真站无法区分。这也是为什么配置里不需要任何证书文件

补充两个术语:VLESS 是极简无状态代理协议,只负责"带一个 UUID 的转发指令",本身不加密,加密交给传输层(即 REALITY 这层)。

对比上一代方案 Trojan:思路类似,但门面是"自己搭的假网站"(自签证书),稽查员细看证书就能识破,所以客户端得开"跳过证书验证"。REALITY 直接借真苹果的门面,高明得多(TV 盒子、老路由器等只认 Trojan 的设备仍会用它)。

NAT VPS:端口映射与转发表 ​

一台典型 NAT 小鸡的转发表(本次实战):

外部端口内部端口用途
5704822SSH
3443720533x-ui 面板
344382081代理入站
344392082Trojan 入站

客户端:订阅与分流 ​

  • 订阅 = 一个返回 YAML/节点列表的 URL;实际自用更常见的是本地 YAML 文件(Clash Verge 导入),内含节点、代理组(手动选择/自动测速)、分流规则。
  • 分流规则:按顺序匹配——局域网直连 → 国内域名(DOMAIN-SUFFIX/GEOSITE,CN,数万条国内域名库)→ 国内 IP(GEOIP,CN)→ 其余全部走代理(MATCH)。实现"国内直连、国外翻墙"。
  • DNS/fake-ip:fake-ip 模式下本地 DNS 返回假 IP,真实域名交给代理服务器在海外解析,绕开本地 DNS 污染;国内域名用 nameserver-policy 指到国内 DNS,保证 CDN 就近。

系统代理 vs TUN 模式(易踩坑) ​

  • 系统代理:macOS 设置里的 HTTP/SOCKS 代理指向 127.0.0.1:7897,自愿制——只有守规矩的应用(浏览器)才把请求交给代理。
  • TUN 模式:虚拟网卡接管整机流量,强制制——任何 App 都跑不掉。
  • 典型反例:Telegram 的 MTProto 协议直连 IP、不走系统代理,开了系统代理它照样连不上(表现为大量 SYN_SENT 卡在 91.108.x.x / 149.154.x.x)——要么开 TUN,要么在 Telegram 内单独配 SOCKS5 代理。

实战踩坑记录 ​

  1. NAT 内外端口对齐:客户端永远填外部端口,转发规则的内部端口必须和入站监听端口一致。
  2. 传递信息以面板为准:密码/UUID 手抄转述错一个字母,认证必失败。
  3. 劣质 NAT 网关对"未生效的转发规则"会做 SNI 代理(把流量送到 SNI 指向的真网站),远程诊断时极易误判成服务器问题——上机 openssl s_client 看本机应答的证书才能分清是服务器侧还是网关侧。
  4. 配置不生效先想到重启 xray:面板数据库里的配置 ≠ 正在运行的配置。

Released under the MIT License.

Copyright © 2023-present