隧道某天早上突然连不上了,第一反应总是怪服务器。但几乎从来都不是服务器的问题。真正变化的,是你和它之间的某个环节,开始去看你数据包的形状,而不只是看它们要去哪儿,判定这个形状就是 VPN,然后把它丢掉了。换到 443 端口没有用,因为端口从来都不是暴露你的原因。
所以这份指南从大多数教程都会跳过的部分讲起:深度包检测到底在匹配什么、为什么 WireGuard 是世界上最容易被指纹识别的隧道协议、以及每一类混淆手段为了穿透过滤各自要付出什么代价 — 随机化流量、借来的 TLS,以及冒充 HTTP/3 的 QUIC。然后才是动手的部分:一个二进制程序、三套能跑起来的服务器配置,以及一套按审查者的方式、而不是按满怀希望的用户的方式去测试结果的方法。这台机器本身可以放在过滤系统触及不到的司法辖区,无需身份证明即可租用,并用Monero支付 — 这一点的分量比听起来更重,最后一节会讲清楚为什么。
深度包检测到底在匹配什么
“DPI”听起来像是个情报问题,但它多数时候只是一次字符串匹配。架设在国家级链路上的过滤系统,没办法对每一条数据流都仔细思考,所以它依赖的是成本最低、最管用的那些信号,大致按下面这个顺序:
- 固定偏移处的协议指纹。WireGuard 会话的第一个数据包是一次握手发起:正好 148 字节,首字节是
0x01,紧接着三个零字节。OpenVPN 则用首字节里的一个操作码、以及一个位置永远不变的会话 ID 来暴露自己。匹配任意一种,每个包只需几条指令、无需保存任何状态,这也是为什么它总是最先被部署的手段。 - 找不到指纹时,看熵。如果一条数据流最初的那些字节均匀随机 — 没有可打印的 ASCII 字符,没有可识别的头部 — 这本身就是一个信号,因为几乎没有合法流量会从第零个字节开始就长这样。过滤系统曾仅凭这一点,就封锁过整类“完全加密”的流量,而这正是随机化协议会掉进去的陷阱。
- 主动探测。过滤系统记下你服务器的地址,然后自己从别的地方发起连接,看它如何回应。一个会应答、以特定方式报错、或者干脆一直占着连接不放的代理,就坐实了这份怀疑。地址就是这样从“也许”变成封锁名单上的一员。
- 长期行为模式。一条长期存在、只连向一个境外地址、携带几百兆字节流量、还带着一条像居民用户的昼夜曲线的数据流,本身就是一种显眼的存在。再怎么混淆载荷也改变不了这一点。
- 地址本身。已知的 VPS 地址段、出现在公开订阅列表里的地址,以及任何商业服务商公开宣传过的地址。这一条审查者不费吹灰之力,也是共享代理地址比协议本身死得更快的原因。
有用的结论是:前三条是你能有所作为的地方,也是这份指南要讲的内容;后两条,则是为什么保护地址那一节绝不是可有可无的附加内容。
为什么把 WireGuard 换到 443 端口没有用
这是这个话题里被重复得最多的建议,效果却几乎为零,原因值得说清楚:特征藏在载荷里,不在端口号里。一个在 148 字节 UDP 数据报偏移零处匹配 0x01 的过滤系统,在 443 端口上找到它,和在 51820 端口上找到它一样轻松。
更糟的是,这一换反而可能让你更显眼。443 端口承载的是 HTTPS,走 TCP;还有 QUIC 和 HTTP/3,走 UDP,但一开始就是可识别的 QUIC 长头部,里面还带着一个 TLS ClientHello。一条既不是这个、也不是那个的 UDP 数据流出现在 443 端口上,在这条链路上其余流量非此即彼的背景下,是个不大不小的异常。
其余那些流传的说法也是一样的道理。改 MTU 改变的是分片方式,不是握手字节本身。给 WireGuard 加一个预共享密钥,加强的是密码学强度,线路格式原封不动。把隧道放到一个不常见的高位端口,在对抗载荷匹配上帮不了你什么,虽然确实能挡掉机会主义扫描器带来的背景噪音。
真正能改变结果的,是改变线路上的内容本身:要么让这些字节看起来什么都不像,要么让它们看起来像审查者已经决定不去封锁的东西。下面的内容,都是这两种做法之一。
能穿透过滤的几大类协议,以及各自的代价
实际可用的做法有四种。它们的排序并非只看强度,因为哪一种合适,取决于你的流量正在经历什么。
- 随机化、无头部的流量 — Shadowsocks-2022。2022 版 AEAD 密码套件(
2022-blake3-aes-128-gcm及同类算法)在线路上完全不留明文头部:从第一个字节起,一个会话就和随机数据没有区别,密钥错了也不会对探测产生任何回应。便宜、快、十分钟就能部署,几乎在任何地方都表现优异。它唯一的弱点就是前面说的熵信号 — 面对一个原则上就封锁一切无法归类的随机流量的过滤系统,看起来什么都不像,并不等于看起来无害。 - 借来的 TLS — 带 Reality 的 VLESS。这是目前实际使用中最强的一个选项。你的服务器会完成一次真正的 TLS 1.3 握手,任何无法通过认证的客户端,都会被原样转发给一个真实的第三方网站,并如实收到那个网站的真实证书。探测方看到的,是一名普通访客连上了一个普通网站——因为事实正是如此。你不需要域名、不需要证书,也不会留下证书透明度记录 — 没有任何地方注册过任何指向你的信息。
- 自己拥有的 TLS — Trojan,或者跑在 WebSocket 之上、挂在 Web 服务器后面的 VLESS。隧道藏在你自己的 HTTPS 网站里,用你自己的域名和证书。概念上更简单,也能和一个真实网站共用同一个地址。代价是这个域名如今成了一个可被烧毁的标识符,证书是 CT 日志里的公开记录,而封锁一个主机名,对审查者来说是个很廉价的动作。
- QUIC 形态 — Hysteria2 和 TUIC。这两者伪装成 HTTP/3,还能把一个真实网站提供给任何没通过认证的连接。选它们的理由通常根本不是审查,而是丢包:在一条丢包率有百分之五到十的链路上,它们能保住吞吐量,而任何基于 TCP 的方案都会崩溃。这里的取舍是真实存在的 — 有些网络会整体限速或丢弃 UDP,如果你把带宽数字填得不诚实,Hysteria 那套激进的拥塞控制还会成为链路上一个糟糕的邻居。
如果你想要一个默认方案:部署 Reality 作为主力,把 Shadowsocks-2022 放在第二个端口上作为备用,只有当你的问题被证明是链路丢包而不是被过滤时,才加上 Hysteria2。这三者都跑在同一个守护进程里,下面的步骤会依次配置每一个。
开始之前,你需要准备什么
比你想的要少。这是个轻量级的负载;真正的约束是带宽和延迟,不是服务器本身。
- 一个小套餐。在任何带 AES-NI 的现代 vCPU 上,加密和 TLS 终止的开销都很低。Pup(1 vCPU / 1 GB / 25 GB NVMe,$3.50/mo)足以轻松承载一条个人隧道;如果是几个人共用,Cub(1 vCPU / 2 GB / 40 GB,$5.00/mo)是更合适的档位;如果是一整个家庭或小团队,还想留点余量,就选 Scout(2 vCPU / 4 GB / 70 GB,$9.00/mo)。每个档位流量都不限量、带宽 1 Gbps,这才是隧道真正在意的那项参数。
- 为路径选对位置。这是人们最容易选错的一步。要挑的是离你最近、且从你这边过去没有被过滤的那个司法辖区,而不是最猎奇的那个:对大多数读者来说,就是 Amsterdam、Paris、Bucharest 或 Sofia;如果人在亚洲,就是 Kuala Lumpur。Reykjavik 和 Zurich 买到的是法律上的距离,不是速度 — 对你托管的东西有用,对你隧道穿过的路径帮助不大。
- 从模板库选 Debian 13 或 Ubuntu LTS。完整的 KVM 虚拟化意味着一个真实内核和属于你自己的网络协议栈,这才让你能够绑定低位端口、整形 UDP 流量,而不用向任何人开口。
- 一个没有历史记录的专属 IPv4。每个套餐都自带一个,外加一段 IPv6 /64。一个从未待在共享代理池里的地址,是这里最值钱的东西,这也是回收利用的廉价云地址活不过几天的原因。
- 先花十分钟做加固。只用 SSH 密钥登录、禁止密码登录、防火墙默认拒绝。Debian 加固清单讲的就是这些;在一台 root 密码能被猜出来的机器上跑混淆隧道,就是在一扇敞开的门上装一把精致的锁。
- 一个域名 — 只有在你选择自己拥有 TLS 这条路线时才需要。Reality 和 Shadowsocks 都不需要域名,这也是它们吸引人的一大原因。
分步操作
- 部署在过滤系统触及不到的地方,并先做好加固
从模板库中选择离你最近、且链路干净的那个位置部署 Debian 13,什么都不做之前,先花十分钟做好基础加固:只用密钥登录 SSH、禁用 root 密码登录、nftables 默认拒绝、开启无人值守安全更新。然后把系统更新到最新,并检查时钟——Reality 需要依赖它:
apt update && apt full-upgrade -y apt install -y curl ca-certificates systemd-timesyncd timedatectl set-ntp true timedatectl status让这台服务器只做这一件事。一条和公开 Web 服务共用地址的隧道,会继承那项服务曾经招来的所有声誉问题。
- 从官方仓库安装 sing-box
一个守护进程就能覆盖全部三种协议,没理由跑三个。要用项目自己的仓库,而不是发行版自带的包,因为这类软件落后一个版本,代价是实实在在的:
mkdir -p /etc/apt/keyrings curl -fsSL https://sing-box.app/gpg.key -o /etc/apt/keyrings/sagernet.asc chmod a+r /etc/apt/keyrings/sagernet.asc printf 'Types: deb\nURIs: https://deb.sagernet.org/\nSuites: *\nComponents: *\nEnabled: yes\nSigned-By: /etc/apt/keyrings/sagernet.asc\n' > /etc/apt/sources.list.d/sagernet.sources apt update && apt install -y sing-box sing-box version这个包自带一个会读取
/etc/sing-box/config.json的 systemd 单元。下面的内容都是在写这一个文件;把你要用的入站配置加进去,不想要的就不写。 - 方案 A——Shadowsocks-2022,十分钟搞定的备用方案
就算 Reality 会是你的主力方案,也先从这个开始,因为它只需要两分钟,还能给你一扇失败方式不一样的第二道门。为密码套件生成一个长度合适的密钥 —
aes-128用 16 字节,aes-256用 32 字节:sing-box generate rand --base64 16然后是入站配置,端口要用一个高位、而不是好记的端口:
{ "log": { "level": "warn" }, "inbounds": [ { "type": "shadowsocks", "tag": "ss-in", "listen": "::", "listen_port": 23456, "method": "2022-blake3-aes-128-gcm", "password": "PASTE_THE_GENERATED_KEY" } ], "outbounds": [ { "type": "direct" } ] }把它写进
/etc/sing-box/config.json,然后执行systemctl enable --now sing-box。注意这里没有 TLS,也不需要拿证书:这里的保护手段,是这份流量完全没有可识别的头部,密钥错了就得不到任何回应。 - 方案 B——带 Reality 的 VLESS,借用别人的 TLS
这是要作为主力运行的方案。先生成密钥对和各项标识符,
PrivateKey留在服务器上,PublicKey给客户端用:sing-box generate reality-keypair sing-box generate uuid openssl rand -hex 8然后是入站配置。
handshake.server是你服务器要冒充的那个真实网站 — 挑一个受欢迎、从你服务器所在位置访问速度快、支持 TLS 1.3、自己在你所在的地方也不太可能被封的网站:{ "type": "vless", "tag": "vless-in", "listen": "::", "listen_port": 443, "users": [ { "uuid": "GENERATED_UUID", "flow": "xtls-rprx-vision" } ], "tls": { "enabled": true, "server_name": "www.cloudflare.com", "reality": { "enabled": true, "handshake": { "server": "www.cloudflare.com", "server_port": 443 }, "private_key": "GENERATED_PRIVATE_KEY", "short_id": [ "GENERATED_HEX" ] } } }把这个对象加进
inbounds数组里、放在 Shadowsocks 那一项旁边,然后用systemctl restart sing-box重新加载。客户端需要五个值:你的地址、443 端口、UUID、公钥,以及 short id — 再加上同一个server_name,这才能让握手保持一致。 - 方案 C——Hysteria2,用在链路丢包而非被过滤的时候
只有在你已经实测出链路存在丢包、基于 TCP 的隧道开始卡顿时,才加上这一个。它走的是 QUIC,所以需要证书 — 要么是你自己域名的真实证书,要么是一对自签名证书,并提前告诉客户端要认这一对:
{ "type": "hysteria2", "tag": "hy2-in", "listen": "::", "listen_port": 8443, "up_mbps": 100, "down_mbps": 100, "users": [ { "password": "A_LONG_RANDOM_PASSWORD" } ], "masquerade": "https://news.ycombinator.com/", "tls": { "enabled": true, "alpn": [ "h3" ], "certificate_path": "/etc/sing-box/cert.pem", "key_path": "/etc/sing-box/key.pem" } }masquerade决定的是一个未通过认证的访客会看到什么:一个指向真实网站的普通 HTTP/3 反向代理,而不是一条会暴露这个守护进程身份的报错。把up_mbps和down_mbps设成你真实能扛住的数字 — 拥塞控制会相信这两个数字,数字虚报只会让你在这条链路上变成一个讨人厌的邻居,而不是一个更快的邻居。 - 只开放你实际用到的端口,其他一律不开
默认拒绝一切,再放行少数几个必须能被访问到的端口。沿用加固指南里的那套 nftables 配置,把隧道用到的端口加进 input 链:
nft add rule inet filter input tcp dport 443 accept nft add rule inet filter input udp dport 443 accept nft add rule inet filter input udp dport 23456 accept nft list ruleset > /etc/nftables.conf有两个细节,比看上去更重要。把 SSH 留在它自己专属的端口上,并且只对你实际会用到的地址开放防火墙,因为一个敞开的 SSH 端口,比这条隧道本身,更能坐实“这是一台有人在远程管理的服务器”这个指纹特征。测试完之后,也不要让测试端口继续监听 — 每多开一个端口,就多给探测方一样可以拿来刻画你的东西。
- 接入客户端,并留一扇备用门
能同时支持这三种协议的客户端,是 Android、iOS、Windows 和 macOS 上的 sing-box 应用,以及 Linux 上配合客户端配置文件使用的同一个
sing-box二进制程序。用你生成的那些值来搭建客户端配置:Reality 需要地址、端口、UUID、公钥、short id 和server_name;Shadowsocks 需要地址、端口、加密方式和密钥。在真正用到之前,就把两种都配置好,并放进同一份配置文件里,这样切换只需要点一下。这样能避开一个特定但常见的故障模式:一次封锁落下来,你唯一在用的那个协议失效了,而唯一能修复服务器的办法,恰恰是一条已经不可能建立的连接。在另一个端口上准备第二种协议,让它的失败方式和第一种不一样,是这份指南里最便宜的保险。
如果你是从一个被过滤的网络内部通过 SSH 管理这台机器,也要确保这条管理路径不依赖这条隧道。
- 像审查者那样去测试,而不是像用户那样
“能连上”是最弱的一种测试。从一台不是这台服务器本身的机器上,检查过滤系统会检查的那三件事:
curl -sv --max-time 8 https://YOUR_IP 2>&1 | grep -E 'subject:|issuer:' nc -vz -w 5 YOUR_IP 23456 nmap -Pn -sV -p 443,8443,23456 YOUR_IP好的结果应该是这样:
curl显示的是你握手目标的证书,看不出任何代理的痕迹;对 Shadowsocks 端口的nc能连上,然后安静地待着直到超时;nmap只识别出一个 Web 服务器,没有其他更值得玩味的信息。如果任何一次探测得到了一个特征鲜明的 banner、一次立即的重置,或者一个能指名这个守护进程的版本字符串,就要在依赖这套配置之前把它修好。然后也要检查一下那些不起眼的故障模式 — 用
systemctl is-enabled sing-box确认服务在重启后依然健在,用journalctl -u sing-box -f确认它在正常使用下是安静的,而不是把每一次连接都记进磁盘日志里。
主动探测,以及懂得保持沉默的服务器
指纹识别负责找出候选对象;探测负责确认它们。一旦过滤系统怀疑某个地址,就会从一个不相关的网络自己发起连接,看看会得到什么回应。一切都取决于这个回应。
一台会返回特征鲜明的错误、在某个特定时刻关闭连接、或者接受一个它根本不可能完成认证的连接的服务器,就坐实了这个猜测。这不是纸上谈兵:大规模过滤系统正是靠这套已被记录在案的机制,成批淘汰过更早期的混淆协议,这也是为什么那些只是把头部打乱的 obfs 类插件,一接触到它就活不下来。
现代设计应对探测的正确方式只有两种:
- 什么都不说。没有密钥,Shadowsocks-2022 就给不出有效回应,所以它干脆什么都不给。在探测方眼里,这个端口就是个黑洞,和一个被防火墙拦住的端口看起来一模一样。它还带有一个时间窗口有限的重放保护,被截获的会话没法之后重发一次去诱出行为特征。
- 说真话,但说的是别人的事。Reality 会把未通过认证的握手转发给一个真实的第三方主机,再把那台主机的真实证书原样带回来。探测方拿到的是一条完全有效的证书链,只不过这个网站显然不是你。挑选握手目标时,要选一个受欢迎、从你服务器所在国家出发合理可达、自己也不太可能被封的网站 — 并且让服务器的时钟保持同步,因为 Reality 会拒绝时间窗口之外的握手。
在信任这套机制之前,自己动手测试一下。从一台不相关的机器上,对着一个 Reality 端口执行 curl -v https://YOUR_IP:你应该看到一张属于握手目标的证书,看不出任何代理的迹象。对着一个 Shadowsocks 端口,nc 应该会挂起,然后超时退出,不返回任何字节。除此之外的任何结果,都是一个值得关注的发现。
地址才是稀缺资源
协议十分钟就能换一个。地址不行。一个 IPv4 一旦在某个国家被封,往往会一直封下去,远远超过触发封锁的那个原因本身消失的时间,因为没人拿钱专门去复核这份名单。把地址当成资产,把协议当成耗材。
由此引出三个习惯。不要公开它。出现在公开订阅列表、频道或者共享配置里的地址是可被枚举的,而枚举是成本最低的攻击手段 — 这就是为什么私有隧道比免费的公共隧道活得长得多。不要给它挂一个可被烧毁的名字。如果你走的是自己拥有 TLS 那条路线,一个同时还服务着某些惹眼内容的域名,会把这个地址一起拖下水。不要混用角色。一台只做一件事的机器,除了你的隧道什么都不跑,就不会继承你在这台机器上做的其他事情招来的封锁记录。
另一半的问题在于地址从哪儿来。周转率高的廉价云服务商,会把 IPv4 在成千上万个短命客户之间循环利用,所以一个“新”地址,在你发出第一个包之前,很可能就已经带着别人的名声了。这里的每个套餐配的都是专属的、经过筛查的 IPv4,而不是共享地址池里的一小块 — 具体定义和自查方法,见干净 IP 到底意味着什么。如果你的地址被标记,或者在什么要紧的地方被封了,就通过面板申请更换;你不应该为了换一个能用的地址而重新下一次单。至于怎么分辨问题出在审查还是声誉名单,我们这篇如何检查一个 IP 是否已被拉黑能帮你分清楚。
混淆做不到的事
这是一份诚实的说明,因为只有把这部分讲清楚,这份指南剩下的内容才值得读。
- 它藏不住你正在往某处发送加密流量这件事。网络运营商依然能看到一条流向境外地址的数据流、它的大小、时间规律,以及持续了多久。Reality 能让这条数据流看起来像一次普通访问一个普通网站;它不会让这条数据流消失。
- 它打不赢流量分析。持续的大流量、带着明显昼夜模式的数据流,依然是显眼的。面对一个愿意在关联分析上真金白银投入、而不只是做模式匹配的对手,载荷混淆就是用错了工具,用可插拔传输层的 Tor,才是研究得更透彻的答案。
- 它保护不了端点。被攻破的设备、已登录的账号、浏览器指纹识别,以及你在对面那一端输入的一切,这些统统不受它的影响。
- 它不能让服务器变得匿名。主机商知道哪个地址是你的,无需 KYC 的注册方式限制的是能知道多少,而不是把这些信息彻底消除。用加密货币付款的 VPS 真的匿名吗这篇里,我们说清楚了哪些看得见、哪些看不见,值得在你依赖任何假设之前花十分钟读一下。
- 它不是永久的。这是一场有发布周期的军备竞赛。今天还管用的配置,明年可能就得换掉,这正是为什么一套你自己掌控、十分钟就能改动的方案,胜过一份你只能取消、却改不了的订阅服务。
它确实能做到、而且做得稳的一件事,是把封锁你的成本,从“线速下的一次字节匹配”,抬高到“决定破坏掉大量正常流量”。实际情况下,这通常就已经是全部的博弈。
司法辖区、支付方式,以及账户为什么重要
协议决定的是数据包能不能穿过去。至于这条隧道能不能一直存在,剩下的一切都是在线路之外决定的。
司法辖区决定的是谁能强制谁做什么。我们的服务分布在荷兰、法国、罗马尼亚、保加利亚、瑞典、冰岛、瑞士和马来西亚这八个地点;在一个辖区有分量的请求,换到另一个辖区可能毫无效力,而且没有一份美式的下架通知,能在这些地方生效。这是如实陈述的运营政策,不是法律豁免 — 当地法院的命令依然适用,也有一条我们绝不会挪动的滥用底线。离岸主机把这中间的区别讲得很清楚。
账户是人们最容易低估的部分。一条隧道能有多私密,取决于“谁租用了它”这份记录本身能有多私密。这里注册只需要一个用来接收凭据的邮箱,仅此而已 — 不需要身份证明、不需要银行卡、不需要地址、也不需要电话。没有什么验证文件要上交,因为我们从来就没收集过。
付款方式是另一半。银行卡会把一台服务器和一份银行记录、一个真实姓名绑在一个我们谁都控制不了的数据库里。这里的结账在链上完成,Monero是头等选项,而不是事后才想起来的备选:我们那篇用 XMR 支付 VPS 费用的指南讲清楚了整个流程,不用信用卡购买那篇则讲清楚了从零加密货币开始该怎么做。确认后大约六十秒就能完成部署,所以万一需要更换地址,几分钟就能搞定。
把这些拼在一起,就是一条能存活下来的隧道该有的样子:一个过滤系统无法低成本匹配的协议,一个没被别人烧过的地址,一个在过滤系统触及不到的司法辖区,还有一个从未持有过任何值得被索要之物的账户。如果你想先从这条隧道最朴素的版本开始,WireGuard 搭建指南只需要十分钟,是个不错的起点 — 等哪天连不上了,再回到这里。
常见问题
为什么我的 WireGuard 隧道一夜之间就不能用了?
几乎总是因为链路上的过滤系统开始匹配这个协议了,而不是因为你服务器上发生了什么变化。WireGuard 的握手是一个固定 148 字节、以 0x01 开头的数据包,在线速下匹配它易如反掌,而且这类规则的上线往往是一次性、大范围铺开的。两个快速验证的办法:服务器是否依然能从别处正常响应 SSH,以及同一条隧道换一个网络是否还能用。如果两者都成立,问题出在链路上,不在这台机器上 — 换端口解决不了。
使用混淆 VPN 合法吗?
在世界上大多数地方,合法 — 加密隧道是再普通不过的基础设施,这类软件也是主流的开源项目。少数国家会对 VPN 使用加以监管或限制,规则从许可要求到彻底禁止不等,所以答案取决于你身处何地,而不是服务器在哪里。我们没有资格就你所在的司法辖区给出法律建议。能说的是我们这边适用的规则:在自己租用的 VPS 上,为自己的流量运行一条私有隧道,属于正常使用;不管哪种情况,我们可接受使用政策的底线 — 不许有 CSAM、不许涉恐 — 都不受影响。
该选 Reality、Shadowsocks-2022 还是 Hysteria2?
主力选 Reality:它在抵御指纹识别和主动探测这两方面都最强,也不需要你自己的域名或证书。Shadowsocks-2022 放在另一个端口上作第二道门,因为它只要两分钟就能配好,而且失败方式不一样。只有在你已经实测出链路存在真实丢包时,才选 Hysteria2 — 它在丢包链路上占优势,换到干净的链路上则没有额外好处。三者都跑在同一个 sing-box 守护进程里,所以这其实是入站配置之间的选择,而不是软件之间的选择。
这需要域名吗?
用 Reality 或 Shadowsocks-2022 都不需要,这也是它们吸引人的一大原因 — 不用注册、不用证书,也不会留下带有你地址信息的证书透明度记录。只有走自己拥有 TLS 这条路线(Trojan,或者跑在 WebSocket 之上、挂在 Web 服务器后面的 VLESS),或者想给 Hysteria2 配一张正规签发的证书时,才需要域名。不用域名,还顺带去掉了一个可以独立于你地址之外被封锁的标识符。
我服务器的 IP 被封了,能直接换一个吗?
可以,而且你不应该为此重新下一次单 — 通过面板申请更换就行。动手之前,先搞清楚到底是什么被记录在案了:一个地址在某个国家境内被封,是一次审查事件;一个地址上了 Spamhaus 或者某个 DNSBL,则是一次原因不同、修复方式也不同的声誉事件,我们那篇黑名单指南会讲清楚整个过程。如果这个地址曾经出现在共享配置或者公开订阅列表里,就该把枚举当成病因,而且不要再公开这个新换上的地址。
混淆会拖慢速度吗?
几乎不会,而且就算有影响,也很少是人们以为的那种方式。近十年任何一款 x86-64 服务器 CPU 都带 AES-NI,所以加密本身不是瓶颈 — 在 1 Gbps 的端口上,瓶颈是网络本身。Reality 只在建立连接时多一次真正的 TLS 握手,之后几乎没有额外开销。Shadowsocks-2022 是三者里最轻的一个。Hysteria2 在丢包链路上可能比其他几种明显更快,在干净的链路上则会略慢一点。真正让你损失延迟的是地理距离,这也是为什么选一个最近的可用位置,胜过选一个最猎奇的位置。
自建的混淆隧道,比商业 VPN 更好吗?
就穿透过滤这件事而言,通常是更好,原因很结构性:商业服务商的地址段是公开的,被成千上万个用户共用,而且可被枚举,所以会被整体封锁,而且一封就不会再解开。你自己的地址只有你一个人在用。这中间的取舍很诚实 — 单用户隧道没有人群可以让你混在其中,所以它在防封锁上远比在防归因上有效得多。你实际面对的到底是这两个问题里的哪一个,才是值得先搞清楚的问题,加密货币付款的 VPS 到底藏得住什么这篇有诚实的拆解。

