中转家宽代理搭建实战：三种架构与完整配置

发布于 8 天前 56 次阅读

家宽的 IP 质量好，但直接用通常不顺手：要么没有公网 IP，要么直连国内延迟高、晚高峰抽风。所以实际用法基本都得配一个中转。

这篇讲三种常见架构、各自的适用前提，以及可以直接抄的配置。先说明一点：很多教程失败的原因是没搞清自己属于哪种情况——家宽有没有公网 IP、是不是 CGNAT，决定你能用哪个方案。

全文以「国内 → 线路机 → 美国家宽」这条链路为实例贯穿：客户端在国内，线路机在美西提供优质入口，落地是美国住宅宽带。这是跨境家宽最典型的用法，也是最后一节完整实例要拆解的对象。

本文属于 VPS 网络与代理链路系列，该系列共六篇，可从此页查看完整阅读顺序与全部索引。

一、家宽为什么要中转

三个现实限制

  • 没有公网 IP：绝大多数家用宽带是 CGNAT（运营商级 NAT），外面的机器连不进来，做不了服务端
  • 上行带宽小：下行几百兆到千兆，上行往往只有 30–100Mbps，这直接决定代理速度上限
  • 直连质量差：家宽线路是按家庭上网优化的，不是按跨境优化，国内直连过去延迟和稳定性都不如专门的线路机

中转要解决的就是这三件事

客户端 ──→ 中转（线路机/云厂VPS） ──→ 家宽 ──→ 目标网站
          ↑                          ↑
     提供好的国内入口            提供干净的落地 IP

中转负责「国内到境外这一段走得顺」，家宽负责「出境之后 IP 干净、能解锁」。分工和主机类型那篇讲的前置/落地关系是一回事。

二、先判断你属于哪种情况

这是选方案的前提，先花两分钟确认：

你的家宽情况 能用的方案 难度
有独立公网 IP（或可做端口映射） 方案 A：DNAT 端口转发 低
CGNAT，无公网 IP 方案 B：反向隧道 中
两种情况都可以 方案 C：两级代理链 中

怎么判断有没有公网 IP？在家宽机器上执行 curl ifconfig.me，然后对比路由器 WAN 口显示的 IP：

  • 两个 IP 一致 → 你有公网 IP
  • 两个 IP 不一致，且路由器 WAN 口是 100.64.x.x / 10.x.x.x / 172.16-31.x.x → CGNAT，走方案 B

三、方案 A：DNAT 端口转发

前提：家宽有公网 IP 且端口可映射，中转机能直接访问到家宽的端口。

3.1 家宽端：跑一个代理服务

最简单的方式是用 X-UI 或直接装 Xray。这里给裸 Xray 的最小配置（/usr/local/etc/xray/config.json）：

{
  "inbounds": [{
    "port": 23456,
    "protocol": "vless",
    "settings": {
      "clients": [{ "id": "家宽UUID", "flow": "" }],
      "decryption": "none"
    },
    "streamSettings": { "network": "tcp" }
  }],
  "outbounds": [{ "protocol": "freedom" }]
}

注意这里不加密、不伪装（security 留空）。因为这一段走的是「中转机 → 家宽」的路径，如果是同机房或同城，或者后续会用隧道包起来，就不需要额外伪装。

启动并确认监听：

systemctl restart xray
systemctl enable xray
ss -lntp | grep 23456

3.2 中转机：DNAT 转发过去

# 开启转发
sysctl -w net.ipv4.ip_forward=1
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf

# 把 443 转发到家宽
iptables -t nat -A PREROUTING -p tcp --dport 443 
  -j DNAT --to-destination 家宽公网IP:23456
iptables -t nat -A POSTROUTING -d 家宽公网IP -p tcp --dport 23456 -j MASQUERADE

# 放行转发流量
iptables -A FORWARD -p tcp -d 家宽公网IP --dport 23456 -j ACCEPT

# 持久化
apt install -y iptables-persistent
netfilter-persistent save

但这样有个问题：443 端口直接裸奔 VLESS 明文，会被识别。所以更常见的是把方案 A 和方案 C 结合——中转机上跑 Reality 入口，出站才是指向家宽的 DNAT/转发。

四、方案 B：反向隧道（CGNAT 家用）

前提：家宽没有公网 IP，必须由家宽主动往外连。

思路是：家宽主动和中转机建立一条隧道，隧道建好后，中转机就能通过隧道内网地址访问家宽。

4.1 WireGuard 反向隧道（推荐）

中转机（有公网 IP，做 WG 服务端）：

apt install -y wireguard

# 生成密钥
wg genkey | tee /etc/wireguard/server.key | wg pubkey > /etc/wireguard/server.pub
wg genkey | tee /etc/wireguard/client.key | wg pubkey > /etc/wireguard/client.pub

cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
Address = 10.66.0.1/24
ListenPort = 51820
PrivateKey = $(cat /etc/wireguard/server.key)

[Peer]
PublicKey = $(cat /etc/wireguard/client.pub)
AllowedIPs = 10.66.0.2/32
EOF

sysctl -w net.ipv4.ip_forward=1
systemctl enable --now wg-quick@wg0
wg show

家宽机（WG 客户端）：

cat > /etc/wireguard/wg0.conf <<EOF
[Interface]
Address = 10.66.0.2/24
PrivateKey = $(cat /etc/wireguard/client.key)

[Peer]
PublicKey = $(cat /etc/wireguard/server.pub)
Endpoint = 中转机公网IP:51820
AllowedIPs = 10.66.0.0/24
PersistentKeepalive = 25
EOF

systemctl enable --now wg-quick@wg0
# 验证：能 ping 通中转机隧道地址
ping -c 3 10.66.0.1

PersistentKeepalive = 25 是关键——CGNAT 的 NAT 表会超时，每 25 秒发个包保活，否则隧道会断。

4.2 中转机转发到隧道地址

隧道通了之后，家宽在 10.66.0.2 上跑代理服务，中转机直接转发过去：

# 家宽上 xray 监听 10.66.0.2:23456
# 中转机转发
iptables -t nat -A PREROUTING -p tcp --dport 443 
  -j DNAT --to-destination 10.66.0.2:23456
iptables -t nat -A POSTROUTING -d 10.66.0.2 -p tcp --dport 23456 -j MASQUERADE

好处：这一段走的是 WireGuard 加密隧道，不需要再叠一层伪装协议。家宽上的 VLESS 可以完全裸跑。

五、方案 C：两级代理链（最通用）

不依赖 DNAT，也不需要 WG 隧道——直接让 Xray 自己串起来。这是最灵活的做法。

5.1 链路结构

客户端 ←─Reality─→ 中转机 ←─裸VLESS─→ 家宽 → 网站

两段用不同的协议强度：

  • 客户端到中转机：走公网，必须伪装 → VLESS + Reality
  • 中转机到家宽：走隧道或同城，不需要伪装 → 裸 VLESS

5.2 家宽端配置

和方案 A 的 3.1 完全一样：监听一个端口，VLESS 无加密无伪装，出站 freedom。

5.3 中转机配置

{
  "inbounds": [{
    "listen": "0.0.0.0",
    "port": 443,
    "protocol": "vless",
    "settings": {
      "clients": [{ "id": "客户端UUID", "flow": "xtls-rprx-vision" }],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality",
      "realitySettings": {
        "show": false,
        "dest": "www.microsoft.com:443",
        "xver": 0,
        "serverNames": ["www.microsoft.com"],
        "privateKey": "中转机Reality私钥",
        "shortIds": ["abcd1234"]
      }
    }
  }],
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [{
          "address": "家宽IP或隧道IP",
          "port": 23456,
          "users": [{ "id": "家宽UUID", "encryption": "none" }]
        }]
      },
      "streamSettings": { "network": "tcp" },
      "tag": "to-home"
    },
    { "protocol": "freedom", "tag": "direct" }
  ],
  "routing": {
    "rules": [
      { "type": "field", "inboundTag": ["vless-in"], "outboundTag": "to-home" }
    ]
  }
}

关键在 outbounds 里那个 vnext 指向家宽——中转机收到客户端流量后，不解包，直接转给家宽，由家宽负责最后的出口。这样客户端看到的出口 IP 就是家宽的 IP。

5.4 验证出口 IP

# 客户端连上后，确认出口是家宽 IP 而不是中转机 IP
curl -4 ifconfig.me
# 或
curl -4 ip.sb

如果输出的是家宽 IP，说明链路通了。

六、协议选择的三个要点

6.1 分段设置强度，别一刀切

链路段 是否过公网审查 推荐协议
客户端 → 中转机 是，走国内国际出口 VLESS + Reality / XHTTP
中转机 → 家宽（隧道内） 否 裸 VLESS / Shadowsocks / SOCKS5
中转机 → 家宽（公网直连） 取决于两端位置 同城用裸协议，跨境加伪装

很多人把两段都配成 Reality，纯属浪费 CPU——隧道内的流量已经是加密的，再叠一层 TLS 只是增加开销。

6.2 家宽段关闭 Mux

家宽的上行带宽小、延迟相对高，Mux 的多路复用在家宽段容易造成队头阻塞。建议家宽端的客户端设置 mux.concurrency = 1（相当于关闭）。

6.3 上行带宽才是瓶颈

家宽下行 500Mbps、上行 50Mbps 很常见。代理速度受限于较小的一端，也就是上行。做速度预期时按上行算，别按下行算。

七、性能调优

7.1 两端都开 BBR

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf
sysctl -p
sysctl net.ipv4.tcp_congestion_control   # 应输出 bbr

7.2 调大 TCP 缓冲区（高延迟链路）

cat >> /etc/sysctl.conf <<EOF
net.core.rmem_max = 67108864
net.core.wmem_max = 67108864
net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864
EOF
sysctl -p

7.3 中转机选得对，比什么优化都有效

中转机是「国内入口」，它的线路质量直接决定体感。选之前先跑一遍 mtr 看回程，别只看商家宣传的线路标签。

八、常见问题

Q：家宽 IP 被封了怎么办？

家宽 IP 被封通常是行为特征问题，不是 IP 本身。先检查：是否长时间高并发、是否跑了明显的代理端口、协议是否裸奔。换 IP 只能缓解，改协议特征才是根治。

Q：链路通了但速度只有几兆？

按顺序排查三个可能：

  1. 家宽上行带宽不够（最常见）——在家宽机上跑 speedtest-cli 看上行实际值
  2. 中转机带宽跑满——看中转机的流量图
  3. Mux 造成队头阻塞——关闭 Mux 再测

Q：为什么延迟比直连家宽还高？

因为多了中转这一跳。中转到家的那一段如果是跨境，会增加 RTT。解决办法是把中转机放在离家和离你都不远的位置（比如家在日本，中转就用日本或香港）。

Q：隧道经常断？

WireGuard 在 CGNAT 后面必须配 PersistentKeepalive。如果还是断，检查运营商是否对 UDP 限速——这种情况下改用 frp（走 TCP）或直接把方案 C 的 xray 链路跑在 TCP 上。

九、三种方案怎么选

方案 A（DNAT） 方案 B（隧道） 方案 C（代理链）
前提 家宽有公网 IP 无公网 IP 都行
配置难度 低 中 中
性能 最好（无额外封装） 好（WG 开销很小） 略高（多重协议栈）
灵活性 低 中 最高（可加路由规则）
推荐场景 家宽公网可达 CGNAT 家用 需要按域名分流

如果三种都能用，优先 A，其次 B，最后 C——越简单越不容易出问题。只有当需要复杂的路由规则（比如某些域名走家宽、某些走直连）时，才值得上方案 C。

十、完整实例：国内 → 线路机 → 美国家宽

前面讲的是三种通用架构，这一节把「国内 → 线路机 → 美国家宽」这条链路从头到尾拆一遍，你可以直接对照自己的情况。

10.1 三段延迟的合理预期

先建立心理预期，避免优化到一半才发现瓶颈本来就在物理距离上。

链路分段 典型延迟 说明
国内客户端 → 线路机（美西） 150–200ms 电信优化线路能压到 150ms 附近，普通 163 骨干晚高峰会到 250ms+
线路机 → 美国家宽 15–25ms 同在美西，这一段非常便宜
家宽 → 目标网站 10–30ms 美国境内访问
端到端 约 180–230ms 受第一段主导

结论：这条链路的性能上限由「国内 → 线路机」决定，占端到端延迟的 80% 以上。所以钱要花在线路机上，家宽段的延迟优化空间很小。

10.2 为什么这条链路通常走方案 A

关键差异在于美国家宽的公网 IP 情况比亚洲好。AT&T、Verizon、Frontier 这类住宅宽带普遍分配动态公网 IP，本机网卡上直接就是公网地址，不是 CGNAT——这意味着「线路机直接连家宽端口」是可行的，不需要打隧道。

判断方法在家宽机上执行：

# 输出的 IP 与本机网卡上的公网 IP 一致 → 有公网 IP，走方案 A
curl -4 ifconfig.me
ip -4 addr show | grep "inet "

如果两者不一致、且本机拿到的是 100.64.x.x 或 10.x.x.x，说明在 CGNAT 后面，改走方案 B。

10.3 家宽端：处理光猫/路由器这一层

美国住宅宽带的网关设备（AT&T 的 BGW 系列、Verizon 的 FiOS 路由器）默认是路由模式，公网 IP 停在网关上，内网机器拿不到。两个办法：

方式 做法 适用
端口转发 在网关后台把外网端口映射到内网机器的固定 IP 只开放个别端口，最安全
IP Passthrough / 桥接 把公网 IP 直接透传给内网机器（AT&T 叫 IP Passthrough，Verizon 叫桥接） 需要机器直接持有公网 IP

推荐端口转发：只暴露一个代理端口，家宽的其它服务不受影响。同时在家宽机上把内网 IP 设成静态（或用 DHCP 保留），否则租约到期 IP 一变，转发规则就失效了。

10.4 动态 IP 的坑：DDNS 必须配

美国家宽的动态公网 IP 会在断线重连、运营商维护后变化。线路机的 iptables 规则如果写死了 IP，家宽一换 IP 整条链路就断，而且现象很迷惑——线路机看起来正常、端口却连不通。

两个解法：

  • DDNS + 脚本更新：家宽上跑 DDNS 客户端，线路机上定时解析域名并刷新 iptables 规则
  • 改用域名而非 IP：如果转发工具支持域名（如 realm、gost），直接写 DDNS 域名，省掉刷新规则这一步

如果用的是方案 C（Xray 链式），在 outbounds.vnext.address 里填 DDNS 域名即可，但要注意 Xray 默认只在启动时解析一次，需要开启 domainStrategy 或定期重启。

10.5 线路机的关键配置

客户端 ──Reality(443)──→ 线路机 ──裸VLESS(23456)──→ 美国家宽 ──→ 网站
                          ↑
                    电信优化线路（这一段决定体感）

线路机同时承担两个角色：对客户端是 Reality 服务端，对家宽是代理客户端。配置骨架就是方案 C 里的那份——inbound 用 Reality，outbound 的 vnext 指向家宽。

如果选择方案 A（DNAT），则线路机上只跑 iptables，不跑 Xray；但这样 443 端口是裸 VLESS，容易被识别。所以实际部署更推荐「方案 A 的转发 + 方案 C 的入口伪装」组合：客户端看到的永远是 Reality，中转机内部才把流量丢给家宽。

10.6 验证链路是否真的走家宽

# 客户端连上后执行，输出应是美国家宽的公网 IP
curl -4 ifconfig.me
curl -4 ip.sb

# 同时在线路机和家宽机上看连接来源，确认流量路径
ss -tnp | grep 23456

如果输出的是线路机的 IP，说明 outbound 没生效（路由规则没匹配或 vnext 写错），流量从线路机直出了——这时候家宽等于白买。

10.7 这条链路的两个典型问题

问题一：速度慢，但延迟正常。先测家宽的上行带宽。美国家宽常见配置是下行 300–1000Mbps、上行 20–50Mbps，代理速度上限就是上行那个数。很多人按下行做预期，结果一直以为是配置问题。

问题二：晚高峰速度腰斩。这是「国内 → 线路机」这一段在拥塞，和家宽无关。用 mtr 对比白天和晚高峰 的丢包率就能确认——末跳丢包从 0% 涨到 5% 以上，就是线路问题。

十一、小结

搭中转家宽的顺序：先确认家宽有没有公网 IP（决定方案）→ 打通「中转到家宽」这一段 → 再配「客户端到中转」的伪装 → 最后验证出口 IP 和速度。

两个最容易踩的坑：一是没确认公网 IP 就去配 DNAT，结果永远连不上；二是两段都上重量级伪装协议，白白损耗性能。分段设置强度，是这套架构的核心思路。

相关阅读

相关文章