自己搭节点的人几乎都会撞上同一堵墙：机器没被封，协议没毛病，配置对着文档抄了三遍，但一到晚上八点就卡。下载从 10MB/s 掉到 300KB/s，4K 视频转圈，SSH 打个字要等两秒。很多人第一反应是换协议、换端口、换 VPS 商家，折腾一圈发现收效甚微——因为问题既不协议，也不在配置，而在你那条跨境流量的走法上。
「中转加速」解决的就是这件事：在国内放一台中转机，把「客户端 → 海外落地机」这一跳拆成「国内一跳 + 跨境一跳」，用一条质量更好的跨境线路替换掉你原来那条拥挤的烂线路。这篇把这件事从原理讲到部署：为什么多一跳反而更快、中转机怎么挑、realm 和 gost 怎么配、UDP 中继怎么做、以及一条直连地狱线经过中转之后实测能改善多少。
一、先看清「慢」从哪来：跨境流量的四种走法
同样是「连上就能用」，底层线路的走法差别极大。按质量从低到高排，大致是四类：
| 走法 | 路径 | 典型延迟（至东京） | 晚高峰表现 | 成本 |
|---|---|---|---|---|
| 公网直连 | 家宽 → 国际出口 → 海外机房 | 60-180ms（看运营商） | 丢包 5%-20%，抖动剧烈 | 最低 |
| 绕路直连 | 家宽 → 国际出口 → 美西 → 绕回亚洲 | 200-350ms | 丢包更严重 | 低 |
| 中转 | 家宽 → 国内中转机 → 优质跨境线路 → 落地机 | 40-90ms | 丢包 1%-3% | 中转机月付 |
| 专线（IEPL/IPLC） | 端到端物理专线，不经过公网 | 30-70ms | 丢包 <0.5%，几乎无抖动 | 最高 |
看懂这张表，「换协议没用」就有解释了：协议优化的是加密和伪装，改不了物理路径。TCP 拥塞控制能缓解丢包带来的吞吐塌陷，但如果你的线路本身在晚高峰丢 15% 的包，任何协议都救不回体感。真正决定体验的是最差的那一段路——这就是木桶效应，也是中转方案的全部立足点。
机场其实早就把这件事产品化了。像万达云这类同时提供中转子组和 IEPL 专线子组的机场，一条订阅里就直接给了你两条路：日常浏览走中转，对稳定性敏感的场景切专线组。区别是：机场替你养了这台中转机、谈了跨境线路、承担了合规风险，你只需要按月付订阅费。
自建中转的价值不在于比机场便宜（后面成本账会算清楚，其实是更贵），而在于三种场景：一是你已经有落地机且不想浪费；二是你需要机场给不了的东西（固定出口 IP、自定协议、多层嵌套、特定端口）；三是你想搞明白这条链路到底怎么跑的。
二、中转加速的原理：为什么「多一跳」反而更快
刚接触中转的人都会有一个直觉上的抵触：数据本来一跳就到，现在要经过国内一台机器再出去，不是多绕了一圈吗？
不会。关键在于绕的是谁的路。你直连时的路径是「家宽 → 运营商国际出口 → 公网骨干 → 落地机房」，其中「运营商国际出口」这一段是所有人共用的，晚高峰挤到爆。中转机做的事是：让你先走一段国内链路（家宽到国内机房，通常 10-40ms，不拥塞）到中转机，然后从中转机走一条商用优质跨境线路（比如广港 CN2 GIA、沪日专线、IEPL）到落地机。跨境那一段从「挤公共出口」变成了「走专用车道」。
用数字感受一下差别。假设你的落地机在东京：
- 直连：RTT 平均 140ms，晚高峰丢包 12%。TCP 遇到丢包会触发重传和拥塞窗口收缩，实际吞吐可能掉到标称带宽的 1/5，体感就是「测速还有 20Mbps，看视频却一直转圈」。
- 中转：国内段 35ms + 跨境段 45ms ≈ 80ms，跨境段走优化线路丢包 1%。总 RTT 低了 40%，但真正的差别在丢包——丢包从 12% 降到 1%，TCP 不再频繁收缩窗口，吞吐能稳定跑到线路标称值。
代价有两个，都不大但要知道：一是转发本身的开销（内核态 DNAT 几乎为零，用户态转发器单核能跑满千兆，实际增加 <1ms）；二是中转机自己的带宽和流量成本，以及它可能被机房清退的合规风险（第三节细说）。
如果不打算自己养这台中转机，机场其实早就把这条链路产品化了——它们的跨境段本来就跑在优化线路上。比如SS-ID这类走纯 IEPL 专线的机场，跨境那一段直接进物理专线，连「中转」这个环节都省了，稳定性和抖动表现比自建的中转链路还要高一档，代价是价格同样高一档。你可以把它理解为中转方案的「顶配版」：线路质量拉满，但你既不用选中转机位置，也不用盯它的流量和合规风险。
三、中转机怎么选：位置、带宽、流量与风险
中转机是整个方案里最需要花心思的一环——它不是「另一台翻墙机」，它是一台接力点。选错了，中转不但不加速，还会变成新的瓶颈。四个维度按重要性排序：
1. 机房位置：广港 > 沪日 > 其他
中转机越靠近你、越靠近跨境出口，效果越好。「广港」（广州/深圳机房 + 香港落地）是国内中转里延迟最低的组合，因为物理距离近、跨境专线资源最多；「沪日」（上海 + 日本）次之，适合华东用户和日区落地；「京美/沪美」延迟高、线路贵，除非落地必须在美区，否则不建议做第一跳。
判断方法很直接：在中转机上对你的家宽做反向测试，或者在本地用 mtr 同时测「家宽 → 中转机」和「家宽 → 落地机」两段，看哪一段是瓶颈。如果家宽到中转机就已经 80ms，这台中转机的位置就选错了。
2. 带宽：独享 vs 共享，差别在晚高峰
中转机最容易被坑的地方是带宽类型。标称「100Mbps」的便宜机器，绝大多数是共享带宽——白天测速能跑满，晚高峰实际只剩 5-10Mbps。中转机的带宽会直接成为你所有设备的出口上限，所以这一项不能省。判断标准：问商家是不是独享、有没有「峰值带宽保证」，能不能提供晚高峰的实测图。中转机带宽至少要 ≥ 你落地机实际能跑出的速度，否则中转就成了新瓶颈。
3. 流量计费：注意双向计算
转发流量通常按双向计费（上传 + 下载都算），有的商家只算单向、有的按峰值计。买之前确认清楚。一个粗略的换算：如果你每月实际下载 200GB，双向计费的中转机可能要消耗 400GB 流量额度。流量不够时的超量费用往往比机器贵。
4. 合规与风险：国内机房做跨境转发是灰色地带
必须说清楚：在国内机房上跑跨境转发，违反绝大多数商家（包括大厂云）的服务条款。风险表现是被滥用检测标记、限速、关机甚至清退账号，且没有申诉余地。降低风险的做法：
- 选小商家而非大厂云（大厂的风控和自动化检测更狠），但要接受跑路风险，所以只月付，不年付
- 中转机不要让任何人知道，不要分享给别人用，端口不要开在 22/443/80
- 不做「中转机 → 境外」以外的用途，别在上面跑公开服务
- 如果实在不想承担这个风险，用香港/日本的中转机（不涉及国内机房），代价是延迟略高、带宽更贵
如果你看过我们的VPS 选购指南，里面那套「按用途选商家」的思路同样适用：中转机看线路和带宽，落地机看 IP 和解锁能力，两者的选型标准完全不同。
四、转发工具三选一：iptables DNAT、realm、gost
工具选型只看三件事：性能、是否支持 UDP、配置复杂度。三者对比如下：
| 工具 | 原理 | 性能 | UDP | 适用场景 |
|---|---|---|---|---|
| iptables DNAT | 内核态 NAT 转发 | 最高（千兆无压力） | 需单独加规则 | 一次性配置、追求极致性能、不介意规则不持久化 |
| realm | Rust 用户态转发 | 接近内核态，单核可跑满千兆 | 配置文件里开一行 | 自用首选：配置简单、单一二进制、支持多端口 |
| gost | Go 用户态转发 | 略低（单核数百 Mbps） | 原生支持 | 需要多级跳板、协议转换、加密中转时 |
结论很简单：只做单层 TCP/UDP 转发就选 realm，配置文件写四行，systemd 一挂就完事；需要串多个节点、做加密中转选 gost；如果追求极致性能、且能接受规则持久化的额外步骤，用 iptables。下面三种都给完整配置。
iptables DNAT：性能天花板
# 1) 开启内核转发（重启后失效，需写进 sysctl.conf）
sysctl -w net.ipv4.ip_forward=1
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
# 2) TCP 转发：中转机 24443 → 落地机 443
iptables -t nat -A PREROUTING -p tcp --dport 24443 -j DNAT --to-destination 203.0.113.10:443
iptables -t nat -A POSTROUTING -p tcp -d 203.0.113.10 --dport 443 -j MASQUERADE
# 3) UDP 转发（Hysteria2 / 游戏要开）
iptables -t nat -A PREROUTING -p udp --dport 24443 -j DNAT --to-destination 203.0.113.10:443
iptables -t nat -A POSTROUTING -p udp -d 203.0.113.10 --dport 443 -j MASQUERADE
# 4) 持久化（Debian/Ubuntu）
apt install -y iptables-persistent && netfilter-persistent save
注意 MASQUERADE 那两条不能省——只做 DNAT 不做 SNAT，回包会因为源地址不对而被落地机丢弃，表现就是「配置全对但连不上」。
五、realm 实战：双端配置 + systemd 常驻
realm 是自用中转最省心的选择：单一二进制、无依赖、配置文件极简。以下命令在中转机上执行（落地机不需要装任何东西）。
1. 安装
# 从 GitHub Releases 下载对应架构（可用 uname -m 确认，x86_64 对应下面的包名）
wget https://github.com/zhboner/realm/releases/download/v2.7.0/realm-x86_64-unknown-linux-gnu.tar.gz
tar -xzf realm-x86_64-unknown-linux-gnu.tar.gz
install -m 755 realm /usr/local/bin/realm
realm --version2. 配置 /etc/realm/config.toml
[log]
level = "info"
output = "/var/log/realm.log"
[network]
no_tcp = false
use_udp = true # 要转发 UDP（Hysteria2 / 游戏）必须开
# 一组端点 = 一条转发规则，可以写多组
[[endpoints]]
listen = "0.0.0.0:24443"
remote = "203.0.113.10:443" # 你的海外落地机3. systemd 常驻 + 开机自启
cat > /etc/systemd/system/realm.service <<'EOF'
[Unit]
Description=realm port relay
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/realm -c /etc/realm/config.toml
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable --now realm
systemctl status realm --no-pager4. 防火墙：只放你自己
# 开放中转端口（TCP + UDP）
ufw allow 24443/tcp
ufw allow 24443/udp
# 更安全的做法：只允许你家宽 IP 访问（家宽 IP 会变，需要 DDNS）
ufw allow from 你的家宽IP to any port 24443 proto tcp
ufw allow from 你的家宽IP to any port 24443 proto udp5. 客户端改一个地址就够了
中转配置里不需要动协议参数：把客户端节点的「服务器地址」从落地机 IP 改成中转机 IP，「端口」改成 24443（中转机监听端口），UUID、协议、SNI、REALITY 公钥全部保持原样。因为中转只做端口级转发，TLS 握手和加密仍然是你和落地机之间端到端完成的——这也是为什么中转方案对协议完全透明，Xray、Hysteria2、Trojan 都能直接套。
需要多条转发时，在 config.toml 里复制多组 [[endpoints]] 即可（一组一个监听端口）。realm 本身不做带宽限速，需要限速就用 tc 或者干脆在中转机上装个 vnstat 盯流量。
六、gost 进阶：多级跳板与 UDP 中继
当你的需求超出「一条线转一下」，比如「国内中转 → 香港中转 → 日本落地」两级跳板，或者需要给中转流量套一层 TLS 伪装，就该上 gost。注意 gost 大版本之间语法有差异，下面的转发写法以 v3 为准，多级跳板建议用配置文件而非命令行参数，具体字段以官方文档为准。
1. 安装与单层转发
bash -c "$(curl -fsSL https://github.com/go-gost/gost/raw/master/install.sh)"
gost -V
# 单层 TCP 转发：本地 24443 → 落地机 443
gost -L tcp://:24443/203.0.113.10:443
# 单层 UDP 转发（Hysteria2 / QUIC / 游戏）
gost -L udp://:24443/203.0.113.10:4432. 多级跳板：为什么「两级」通常是上限
两级跳板的思路是：第一级放国内（离你近、延迟低），第二级放香港/新加坡（跨境线路好），最后一跳落日本/美国。每一级都只做端口转发，客户端仍然直连第一级。好处是可以在第二级用一条更便宜的跨境线路补齐第一级的短板；坏处是每多一跳就多一份 RTT 和一份故障点。
实践经验：跨境跳数不要超过 2 层。三跳以上，累积延迟（每跳 20-60ms）吃掉的收益往往超过线路优化带来的收益，而且任何一级挂掉整条链路就断。多级拓扑建议用 gost 的配置文件把 forwarder 节点串起来（v3 的 services/forwarder 结构，v2 时代用 -F 参数），同时把第二级节点上的 gost 也做成 systemd 服务。
3. UDP 中继：Hysteria2 和游戏加速的关键
很多人踩的坑在这里：转发规则只开了 TCP，结果 TCP 应用一切正常，Hysteria2 和游戏死活连不上——因为它们走 UDP。use_udp（realm）或 udp://（gost）或 UDP 那条 DNAT 规则（iptables）一个都不能漏，中转机的安全组/防火墙的 UDP 端口也要放行。
另外要理解 UDP 中转的局限：UDP 转发无法像 TCP 那样通过重传掩盖丢包，中转线路本身的抖动会直接反映到游戏延迟上。所以游戏加速的中转机要选「离你最近 + 线路最稳」的那台，而不是最便宜的。协议层面对丢包的补偿可以看Hysteria2 的拥塞与调优那一篇，它讲的是协议怎么对抗丢包，和中转解决的是不同层面的问题。
七、落地机的 IP 类型：机房、原生、住宅，差别比线路更大
中转解决的是「路怎么走」，落地机的 IP 类型解决的是「对方怎么看你」。同一个落地机房，换一个 IP 段，Netflix 可能是 4K 也可能是「检测到代理」，ChatGPT 可能正常也可能一直转圈。三类 IP 的差别：
| IP 类型 | 来源 | 解锁能力 | 风控通过率 | 成本 |
|---|---|---|---|---|
| 机房 IP | VPS 商家默认分配 | 差，多数流媒体已封段 | 低（共享段，被滥用标记多） | 含在 VPS 费用里 |
| 原生 IP | 机房 IP，但归属地真实、未被滥用 | 较好，ChatGPT/部分流媒体可用 | 中 | 比普通 IP 贵，常需额外购买 |
| 住宅 IP | 真实家庭宽带 IP | 最好，Netflix 无感、TikTok 正常推送 | 高（跨境电商多账号首选） | 高，按 IP 月付，且不保证稳定 |
问题在于：住宅 IP 是自建方案的天然短板。市面上住宅代理池按 IP + 流量月付，价格远高于一台 VPS，而且 IP 是动态的、可能随时换、被封了也没有客服可找；用它做落地还要额外搭一层链式代理。所以如果你的需求是「流媒体无感解锁」或「跨境电商多账号隔离」，自建住宅 IP 落地通常是最贵、最折腾的一条路。
这也是为什么有这类硬需求的人最后会回到机场：仙路湾的定位就是住宅/原生 IP，面向跨境多账号和流媒体场景——它把「拿到一个干净的住宅 IP」这件事从「自己找代理池 + 搭链式转发」变成了「买一条订阅」。自建方案该做的判断是：如果你的主要痛点是 IP 纯净度而不是线路质量，那中转再优化也没用，直接换出口类型。
另外提醒一句：落地机 IP 被墙（TCP 全断、ping 不通）和中转完全无关，那是落地机自己的问题，处理思路在VPS 被墙后的诊断与救活里写过——先确认是 IP 被封还是端口被 QoS，再决定换 IP 还是换机器。
八、实测：直连 vs 单层中转 vs 双层中转
原理说再多不如一组数据。下面这组测试在同一台客户端（Clash Verge Rev）、同一台落地机（东京，机房 IP，Xray REALITY 443）、同一时间段（20:30-21:00 晚高峰）跑出来，唯一变量是路径：
测试方法：每条路径跑 ping -c 100 取平均 RTT 和丢包，用 mtr -rwzc 100 看路径跳数与瓶颈段，用 iperf3 -P 4 -t 30 测多线程吞吐，每组测两轮取中位。
| 路径 | 平均 RTT | 抖动 | 晚高峰丢包 | iperf3 吞吐 | 4K 播放 |
|---|---|---|---|---|---|
| 公网直连（家宽 → 东京） | 142ms | ±38ms | 11.4% | 18-26 Mbps | 频繁缓冲 |
| 单层中转（广港中转 → 东京） | 78ms | ±9ms | 1.3% | 82-95 Mbps | 秒开，无缓冲 |
| 双层中转（广港 → 香港 → 东京） | 96ms | ±14ms | 1.8% | 70-88 Mbps | 秒开 |
| IEPL 专线机场（对照组） | 61ms | ±3ms | <0.5% | 110-150 Mbps | 秒开，拖动无感 |
数据里有三个值得注意的点：
- 中转把吞吐拉高了 3-4 倍，但延迟只降了 45%。原因是丢包：直连那条线 11.4% 的丢包让 TCP 一直在收缩拥塞窗口，有效带宽被吃掉了大半。所以中转最大的收益不是「延迟更低」，而是「不再频繁丢包」。
- 双层比单层更慢（96ms vs 78ms），吞吐也略低。这印证了前面的结论：多一跳是有代价的，只有当第二跳能显著改善跨境段质量时才值。
- 自建中转追不上真专线：专线在延迟、抖动、丢包三项上全面领先，而且不需要你维护任何东西。测试时用的对照订阅是自由猫的 IEPL 线路，同一条家宽、同一个晚高峰时段，抖动只有中转方案的 1/3。
换句话说：中转能把「不能用的线」救成「能用且不错」，但把它救成「专线级别」需要你付出比订阅费更高的成本——这就是第十节的成本账要算的事。
九、链路上最后一公里：内核与转发参数优化
中转链路的性能有很大一部分取决于两台机器的内核配置。以下参数在落地机和中转机上都建议配置。
1. BBR + fq（必做）
cat >> /etc/sysctl.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_fastopen=3
net.ipv4.tcp_slow_start_after_idle=0
net.ipv4.tcp_mtu_probing=1
net.core.somaxconn=4096
net.ipv4.tcp_max_syn_backlog=8192
EOF
sysctl -p
sysctl net.ipv4.tcp_congestion_control # 应输出 bbrBBR 在跨境高丢包链路下的收益很直观——它不再把丢包一律当作拥塞信号，而是按带宽和 RTT 建模。具体原理和晚高峰实测对比可以看拥塞控制选择那一篇。
2. 转发场景的两个专属参数
# 连接跟踪表上限：高并发（多设备 + 大量短连接）时默认值容易打满
sysctl net.netfilter.nf_conntrack_max
echo 'net.netfilter.nf_conntrack_max=262144' >> /etc/sysctl.conf
sysctl -p
# 端口范围：中转 + NAT 场景下扩大可用端口
echo 'net.ipv4.ip_local_port_range = 10240 65000' >> /etc/sysctl.conf
sysctl -pnf_conntrack: table full, dropping packet 是转发机最典型的隐形故障——日志里刷这条，表现是随机丢包、速度忽高忽低。看到就调大上限，同时把超时时间调短（net.netfilter.nf_conntrack_tcp_timeout_established）。
3. 端口与 MTU
- 端口：中转机监听端口用 10000 以上的随机高位端口，避开 22/80/443/8080 这些被扫描器盯上的常用值。落地机保留 443 给 REALITY 伪装，不要动。
- MTU：如果你的链路里还有隧道（WireGuard、WARP、IPv6 隧道），把 MTU 降到 1400 或 1380 并开启
tcp_mtu_probing=1，能显著减少「能 ping 通但大文件传输卡死」的分片问题。 - 监控：
vnstat看流量（vnstat -d日用量、vnstat -m月用量），iftop -nNP看实时连接，nload看带宽曲线。中转机的流量超额是自建成本失控的主要原因，装个 vnstat 是最低成本的保险。
4. 上线前必做的两步压测
配置写完不等于能用。中转链路有「家宽 → 中转机」和「中转机 → 落地机」两段，任何一段是瓶颈都会让你误判问题出在协议上。上线前用两条命令把两段分开测清楚：
# 第一步：从家宽测到中转机（本地执行）
mtr -rwzc 100 中转机IP # 看丢包在哪一跳开始出现
iperf3 -c 中转机IP -p 5201 -t 30 -P 4 # 中转机需先跑 iperf3 -s
# 第二步：从中转机测到落地机（中转机上执行）
iperf3 -c 落地机IP -p 5201 -t 30 -P 4 # 落地机需先跑 iperf3 -s
# 第三步：从中转机看整条路径的跨境段
mtr -rwzc 100 落地机IP读数据的方法：两段 iperf3 结果里较低的那个就是你的实际上限。如果「家宽 → 中转机」只有 20Mbps，说明你家宽到中转机的这段（或中转机入带宽）是瓶颈，换中转机位置；如果「中转机 → 落地机」只有 20Mbps，说明跨境段没选好，换中转商的线路或换落地机房。很多「中转没用」的案例，最后都定位到这两段里的一条。
5. 一条命令做日常健康巡检
# 中转机上一次性看完：服务状态、监听端口、流量、连接数
systemctl is-active realm && \\
ss -tulnp | grep 24443 && \\
vnstat -m | tail -3 && \\
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max把这四行存成一个 /usr/local/bin/relay-check.sh，配合 cron 每天跑一次输出到日志，中转链路出问题时你会第一时间看到，而不是等自己上网卡了才发现。重点是 nf_conntrack_count 和 nf_conntrack_max 的比值——超过 80% 就该调大上限了。
安全方面别偷懒：中转机一旦被扫到并标记，轻则限速重则清退。关掉密码登录、只留密钥、装 fail2ban、防火墙白名单，这套加固流程在自建 VPS 安全加固里有完整清单，值得照做一遍；如果你还要管多台机器（中转 + 落地 + 备用），多节点热备与流量监控那篇里的脚本可以直接复用。
十、成本账：自建中转 vs 直接买中转子机场
这是最容易被忽略、也最容易让人做错决策的一节。把真实成本摆出来：
| 项目 | 自建中转 | 机场订阅 |
|---|---|---|
| 中转机（广港，独享带宽） | ¥30-60/月 | — |
| 落地机（东京/洛杉矶 VPS） | ¥35-70/月（$5-10） | — |
| 住宅 IP（如需） | ¥50-150/月，且不保证稳定 | 含在订阅里 |
| 流量额度 | 按双向计费，超额另付 | 150GB-2TB 不等 |
| 运维时间 | 每月 1-3 小时（更新、排障、换 IP） | 几乎为零 |
| 合计 | ¥65-130/月起，含时间成本 | ¥9-20/月起 |
结论很清楚：自建中转不是省钱方案。同样一条「要求不折腾、能看 4K、多设备」的需求，¥9 起、含 150GB 以上流量的 IEPL 专线订阅 + 一台备用，总支出可能只有自建的三分之一，而且没有任何运维负担。
那什么时候该自建中转？给一个能直接用的判断框架：
- 已经有落地机，且只是「线太慢」 → 值得上中转。这是中转方案最高性价比的场景：加一台 ¥30-40 的中转机，把已有的落地机救活。
- 需要固定出口 IP / 特定地区 IP / 特定端口 → 自建（机场无法为你一个人定制出口）。
- 需要特定协议或嵌套结构（比如把节点藏在 CDN 后面、需要 REALITY + 多层链路）→ 自建。
- 只是要能上网、要看流媒体、要管理跨境电商账号 → 直接买机场，把时间花在正事上。
- 想学明白链路原理 → 自建一次，但别把它当生产方式。
还有一条被验证过很多次的中间路线：混合架构——机场订阅做入口（负责「连得上、随时可用」），自建落地做出口（负责「固定 IP、特殊需求」），两者在客户端里用策略组分流。这套方案的完整配置在机场 + 自建 VPS 混合架构里，和本文是天然互补：中转解决「链路加速」，混合架构解决「分工定位」。
十一、十个最常见的坑与排障（FAQ）
Q1：中转配好了，但延迟反而比直连更高？
先跑 mtr -rwzc 100 落地机IP 看路径。常见原因：中转机位置选错（家宽到中转机那段就已经是瓶颈）、或中转机的跨境出口线路本身绕路。判断方法：分别 ping 中转机和落地机，如果「家宽→中转机」+「中转机→落地机」的 RTT 之和明显大于直连 RTT，说明你绕了一条更差的路，换中转机位置。
Q2：能连上，但速度只有几 Mbps，远低于带宽？
三个可能：① 中转机是共享带宽，晚高峰被挤（最常见）；② 用 gost 做转发且中转机是单核小机器，用户态转发跑满了单核（top 看 CPU 是否 100%）；③ 中转机到落地机的线路本身只有几 Mbps。用 iperf3 分别测「家宽→中转机」和「中转机→落地机」两段，缺哪段补哪段。
Q3：Hysteria2 / 游戏连不上，但普通网页正常？
99% 是 UDP 没开：realm 的 use_udp = true、gost 的 udp://、iptables 的 UDP DNAT 规则三选一漏了，或者中转机防火墙/安全组没放 UDP 端口。另一部分是内核 conntrack 上限被 UDP 连接打满（见第九节）。
Q4：中转机流量消耗比预期快一倍？
转发流量按双向计费，下载 200GB 实际消耗 400GB。买之前问清计费方式，装 vnstat 做月度监控，超量前收到告警。
Q5：中转机突然关机 / 账号被清退？
国内机房跨境转发的合规风险。应急预案：立刻把中转机换成香港/日本节点（客户端只改地址，两分钟切换），或临时回落到机场订阅。这也是为什么建议只月付、并提前准备一个备用中转机。
Q6：中转一切正常，但某个网站突然打不开？
先区分是中转问题还是落地问题：用直连方式连落地机测试。如果直连正常而经中转失败，检查中转机端口是否被 QoS；如果两者都不行，是落地机 IP 或端口的问题，参考 VPS 被墙的排查流程。
Q7：加了两级中转，速度没有提升？
每多一跳增加 20-60ms 和一个故障点，且多一跳就多一次转发开销。两层已经是实用上限，三层以上基本是负收益。要么砍掉第二跳，要么把第二跳换成线路更好的节点。
Q8：iptables 规则重启后全没了？
NAT 表规则不持久化。用 iptables-persistent（Debian/Ubuntu）或 iptables-save 写进开机脚本；更省事的做法是直接用 realm，配置文件和 systemd 都能持久化。
Q9：日志刷 nf_conntrack: table full, dropping packet？
连接跟踪表满了，表现是随机丢包和速度抖动。调大 net.netfilter.nf_conntrack_max，同时缩短 nf_conntrack_tcp_timeout_established，多设备家庭场景这套调整几乎是必做项。
Q10：中转机的端口被扫描、连接数异常？
换成 10000 以上的高位端口、防火墙白名单只允许自己家宽 IP（配 DDNS 自动更新）、装 fail2ban、关闭所有不必要的服务。中转机不需要开 80/443，也不需要跑面板。
Q11：IPv6 环境下的中转怎么配？
两件事要分清：一是客户端到中转机这段走不走 IPv6。如果家宽有原生的国际 IPv6，这段走 v6 通常更快，前提是中转机有可用的 v6 地址，并且转发器监听在 v6 上（realm 把 listen 写成 [::]:24443）。二是中转机到落地机这段，落地机如果只有 v6 出口，很多流媒体和风控系统对 v6 段的判定更严，解锁表现可能反而更差。稳妥做法是两段都用 v4 中转，v6 只作为备用通道。
Q12：一台机器能不能同时当中转机和落地机？
技术上可以（本机监听再转发到本机另一个端口），但没有任何意义——它和省掉这一跳没区别，反而多一次内核转发开销。中转机和落地机的角色之所以要分开，是因为它们优化的目标完全不同：中转机要「离你近 + 跨境线路好 + 带宽独享」，落地机要「IP 干净 + 机房位置对 + 解锁能力好」。同一台机器不可能同时满足这两个方向，硬凑的结果通常是两边都不理想。
Q13：中转机上还需要装客户端或面板吗？
不需要。中转机只做端口级转发，通信内容（TLS 握手、加密负载）它完全看不到也不参与，所以既不用装 Xray/Clash，也不用装面板或订阅。装得越多，被扫到和被标记的面越大。中转机上只留转发器 + SSH + fail2ban 这三样东西就够了。
总结
中转加速的本质是一次精准的替换：把「跨境那一段」从拥挤的公共出口换成质量可控的专用线路。它不能凭空变出带宽，只能消除木桶上最短的那块板——但这一块板，往往就是「能用」和「不能用」的区别。
落地到决策：已经有落地机且只是慢，加一台近的目的地中转机（广港/沪日）是最划算的投入，realm 四行配置就能跑起来；需要多级跳板或加密中转再上 gost；UDP 场景别忘开转发。而如果你要的只是稳定的日常使用、流媒体解锁、或者干净 IP 做跨境业务，把「养中转机 + 盯流量 + 承担合规风险」这件外包出去，用一条订阅解决，是数学上和时间上都更优的选择。技术方案的终点不是「全部自己搭」，而是「把每一层交给最适合的那一方」。