# The Right Way to Use WebArena Indigo

> WebArena Indigo is a cheap, good-value Japanese VPS that makes a great landing node. But if you front it with a relay and push traffic over a GRE tunnel like I did, GRE over IPv4 gets rate-limited the moment you run a speed test — the connection collapses right after the first burst. This post walks through what I tried (realm public forwarding, IPv4 GRE, IPv6 GRE) and how I ruled out snell, MTU, DNS and the qdisc one by one, landing on the conclusion that only GRE over IPv6 (ip6gre) reliably escapes the rate limiting. Plus a note on picking between the 500M/4-core and 1000M/6-core shared plans.

Author: Vincent Yang
Published: 2026-06-17
Tags: WebArena Indigo, VPS, GRE, IPv6, Network
Source: https://missuo.me/posts/webarena-indigo-ipv6-gre

---

> 最近在折腾日本落地节点，用的是 WebArena Indigo（下文简称 Indigo）。这家日本 VPS 便宜、走 NTT 线路，拿来做落地很合适。但我在「中转机 + Indigo 落地」这套架构上踩了个不小的坑，折腾了大半天才定位清楚，这篇就记录一下整个过程和最后的解法。

## 架构与需求

需求很简单：用 Indigo 当日本落地，但 Indigo 的直连 IP 从国内访问的路由一般，所以前面再挂一台**中转机**（线路对国内友好），客户端连中转机、中转机把流量送到 Indigo 落地。

```
客户端 → 中转机 → (隧道) → Indigo 落地（snell）
```

落地这台 Indigo 上跑的是 snell，中转机负责把入口端口的流量转发过去。问题就出在「中转机 → Indigo」这一段该怎么走。

## 为什么没直接用 realm 公网转发

最省事的做法当然是 realm（或 gost 之类）做个普通的公网 TCP 转发，中转机监听一个端口，直接转到 Indigo 的公网 IP。

但在 Indigo 上，**走公网转发是百分之百会被限速的**——把流量从中转机公网直接灌到落地的公网 IP，必然撞限速。所以 realm 这条路直接 pass，我给两台机器之间建了一条 **GRE 隧道**，想着把流量「包」进点对点的隧道里、看起来像内网互联，应该能躲过针对公网中转的限速。

> 剧透一下：隧道这个方向是对的，但只对了一半——**IPv4 GRE 照样会被限速**，一上量就崩；最后只有 IPv6 的 GRE 才真正躲过去。

## IPv4 GRE 的坑：一跑测速就崩

隧道建好后，节点能连、能上网，平时刷网页也没问题。但只要一**测速**，现象非常稳定：

- 第一波数据能冲出去（一两秒、十几 MB），
- 紧接着直接 `Socket closed by remote peer`，测速被打断，
- 换任何别的节点都正常，唯独这条经 Indigo 落地的会崩。

把 snell 摘掉、直接在隧道内裸跑 iperf3，问题原形毕露：

| 方向 | IPv4 GRE |
| --- | --- |
| 落地 → 中转（即下行/测速方向） | ~198 Mbps，**一路下滑**，重传 2.8 万+ |
| 中转 → 落地 | ~475 Mbps，重传几千 |

下行方向 8 秒重传两万八，吞吐从 235 一路掉到 154——**典型的「一上量就被狠丢包、TCP 雪崩、连接被 reset」**。这就是测速「第一下能跑、马上断」的根源。

## 排查：把嫌疑一个个排除

为了不冤枉好人，我把可能的原因逐个排掉：

- **不是 snell**：直接连中转机本机的 snell（不经隧道）完全正常，说明协议和版本没问题。
- **不是 MTU**：两个方向用 DF 大包打满 1500 都能过，隧道内 1450 也能过，简单的 GRE 黑洞排除。
- **不是 DNS / 出网**：在落地机本机 `curl` 直连测速源，5MB 秒下，出口带宽、源站、解析全都好的。
- **不是 qdisc 丢的**：落地机网卡用的是 `cake`，但它 `bandwidth unlimited`，整个生命周期只丢了几百个包，根本没在限速。

也就是说：**包不是在落地机的队列里丢的，是出了落地机之后、在到中转机的这段公网链路上丢的。** 落地机本机直连测速源又是满速的（出网和源站都没问题），所以矛头指向：**这条路径对 GRE（协议 47）这种隧道流量，在高速率下做了限速 / 丢包。**

更有意思的是，后来我拿另一台 Indigo（同机房、邻近子网）裸测**不带任何 GRE 的 IPv6 直连**，重传也高达四万多。这进一步说明：底层路径本身对大流量就一般，而 IPv4 + GRE 是被额外「针对」的那一层，叠起来就直接雪崩了。

## 解决：改用 IPv6 GRE（ip6gre）

两台机器都有 global IPv6，而且 v6 之间互 ping 延迟低、空载零丢。运营商的 QoS / policing 规则又常常**只配了 IPv4**，IPv6 那条路往往更干净、没人管。于是我把隧道的**外层**从 IPv4 GRE 换成 IPv6 GRE（`ip6gre`）——内层地址（`10.0.0.x`）和上面的转发规则一个字都不用动，只换「管子外面」。

换完立刻见效：

| 方向 | IPv4 GRE | IPv6 ip6gre |
| --- | --- | --- |
| 落地 → 中转（测速方向） | ~198 Mbps，持续塌 | **~470 Mbps，稳定还上扬** |
| 中转 → 落地 | ~475 Mbps | ~460 Mbps |

最关键的是：**不再雪崩了**。测速方向稳稳跑到带宽上限附近，Surge 那边也不再 `closed by peer`。残余还是有一些重传（这条路底子就一般），但 TCP 能正常「骑」过去，不影响使用。

**所以这篇的核心结论就一句话：在 Indigo 上做隧道中转，只有 IPv6 的 GRE 才能保证不被限速。**

### 配置要点

建隧道（两端对称，把 `local` / `remote` 和内层地址对调即可）：

```bash
# 中转机一端
ip link add tun-gre type ip6gre \
  local <中转机 IPv6> remote <Indigo IPv6> \
  ttl 255 encaplimit none
ip addr add 10.0.0.2/30 dev tun-gre        # 落地机用 10.0.0.1/30
ip link set tun-gre mtu 1400 up
```

几个容易忽略的点：

- **MTU 要降下来**。IPv6 外层比 IPv4 多 20 字节开销（IPv6 头 40 + GRE 4 = 44），1500 的底层算下来内层最多 1456。我直接设成 **1400**，留足余量，反正丢包不是 MTU 问题。
- **`encaplimit none`**。`ip6gre` 默认会塞一个 IPv6 封装限制扩展头，多 8 字节还可能被某些路径丢，关掉更干净。
- **记得做 MSS clamp**。在隧道接口上把 SYN 的 MSS 按隧道 MTU 夹一下（nftables `tcp option maxseg size set rt mtu`），不然某些方向的大包还是会顶破隧道。
- **持久化别忘**。我两台一台用 `systemd-networkd`（`.netdev` 里 `Kind=ip6gre`），一台用 `ifupdown`（`/etc/network/interfaces.d/`），改完都要落盘，不然重启就回去了。
- 内层还是 IPv4 的 `10.0.0.x`，所以日常验证隧道通不通**还是 `ping 10.0.0.1`**（穿隧道、外层用 v6 封装）；ping 那串 v6 地址只是测两台公网底层，跟隧道本身没关系。

## 选机器：500M 四核 vs 1000M 六核共享

顺带说下套餐。我手上两台 Indigo：

- **A：500M 带宽 / 四核** —— 日常落地中转，**完全够用**，能稳定跑到带宽上限附近。
- **B：六核 / 1000M「共享」带宽** —— 理论规格更高，但实测**没必要**。

原因有两个：一是那 1000M 是**共享**带宽，不保证；二是这套架构真正的瓶颈在**中转那段链路和路径质量**，不在落地机的标称带宽——换上 B 之后单条隧道也跑不出比 A 更高的有效吞吐。所以为了这个用途，**500M 四核那档就够了，没必要上 1000M 共享**，省下的钱多开一台或者升级中转机更划算。

## IP 质量

顺手也跑了下这几个 IP 的质量测试，贴出来给个参考：

![WebArena Indigo IP 质量测试 3](https://r2.uid.ac/blog/20260617618e3da0.png)

![WebArena Indigo IP 质量测试 2](https://r2.uid.ac/blog/20260617441b7391.png)

![WebArena Indigo IP 质量测试 1](https://r2.uid.ac/blog/202606173d6eecea.png)

## 小结

- Indigo 做隧道中转，**IPv4 GRE 会被限速到雪崩，IPv6 GRE（ip6gre）才稳**——这是这次最大的收获。
- **公网转发在 Indigo 上是百分之百会被限速的**，所以必须走隧道；但别以为建了隧道就万事大吉——IPv4 GRE 一样会被限，只有 IPv6 GRE 能稳。
- 隧道丢包先别急着怪 GRE「性能差」：GRE 本身是很薄的内核封装，能跑千兆。先用 iperf 在隧道内裸跑、再和普通 TCP 直连对比，很快就能区分是「协议被限」还是「路径本身烂」。
- 套餐别被规格忽悠，**500M 四核足矣，1000M 共享对这个场景没意义**。