[Routing server] RFCHOST JP2CO / JP2CO Lite Tokyo, Japan: China Telecom 163PP, China Unicom/Mobile 4837, evening peak speed tests and international connectivity comparison

The VPS itch struck again, so I tested two RFC Japan route machines to see how they perform after the route switch.

Evening-peak mainland speed tests are in section 5, and international connectivity is in section 7.

Contents

1. Configuration
2. Node Quality
3. Mainland China three-network outbound route test
4. Mainland China three-network TCP Ping
5. Evening peak single-thread speed test
6. Website & DNS speed tests
7. International connectivity
8. Speedtest multi-thread speed test
9. Summary

1. Configuration

These are the original configurations of the two models. I upgraded mine through the prize wheel, so the actual configuration should prevail.

2. Node Quality

bash <(curl -sL https://run.NodeQuality.com)

💻Basic information

JP2CO	JP2CO Lite

🎬IP quality

The IP quality of both is poor. The CO range has already been heavily flagged by many neighbors, but DNS unlocking is available.

JP2CO	JP2CO Lite

🌐Network quality

JP2CO	JP2CO Lite

📍Return route

NQ's display seems a bit off. Unicom and Mobile are both 4837; Telecom was just switched and should be 163PP.

JP2CO	JP2CO Lite

3. outbound route (itdog.cn）

🇯🇵 JP2CO

Telecom uses direct 163, Unicom uses 4837->NTT, Guangzhou Mobile uses CMIN2, and Shanghai/Beijing Mobile use CMI->IIJ.

Location	China Telecom	China Unicom	China Mobile
Beijing
Shanghai
Guangzhou

🇯🇵 JP2CO Lite

All three networks use their respective backbones to SoftBank; Unicom outbound has severe packet loss.

Location	China Telecom	China Unicom	China Mobile
Beijing
Shanghai
Guangzhou

4. TCP Ping（itdog.cn，2025-11-20 23:30）

Lite's Unicom route is somewhat broken.

JP2CO	JP2CO Lite

5. Proxy speed tests (2025-11-20 23:00-24:00)

I tested during evening peak. The speeds of the two are not very different; some regions favor one or the other. Some nodes can even trade blows with GoMAMi JP.
Telecom and Unicom latency is higher than DMIT Shinagawa, and CO Lite's Unicom latency is more than double CO in some places.
Mobile latency is quite high, but speeds are good.

🇯🇵 JP2CO

[Telecom speed-test records] | [Unicom speed-test records] | [Mobile speed-test records]

🇯🇵 JP2CO Lite

[Telecom speed-test records] | [Unicom speed-test records] | [Mobile speed-test records]

6. Website & DNS speed tests

bash <(wget -qO- https://raw.githubusercontent.com/Cd1s/network-latency-tester/main/latency.sh)

Telegram was probably a script issue and did not get measured.

🇯🇵 JP2CO

Website latency	DNS resolution

🇯🇵 JP2CO Lite

Website latency	DNS resolution

7. International connectivity - iPerf3 TCP IPv4 Single-threadspeed test (10 seconds per run, 2025-11-21 11:20-11:45)

The local port is large and can basically reach 5Gbps. Asia-Pacific is also good. If you won a high-traffic prize-wheel upgrade, it can be used as a T1 landing node. US West return uses NTT; pulling to Seattle is just average, while Los Angeles is good in both latency and speed.

RFC has some issues to BAGE JP (GSL) and DMIT LAX T1.

🇯🇵 JP2CO

[Test records]

🇯🇵 JP2CO Lite

[Test records]

Japan-US routes

The two are actually similar, both returning via NTT. To Misaka Seattle, outbound goes Misaka->GSL. To Nube SJC, outbound uses internal network, but Lite's return route detours.

🇯🇵 CO <-> 🇺🇸 Misaka SEA	🇯🇵 CO <-> 🇺🇸 Nube SJC	🇯🇵 CO <-> 🇺🇸 BAGE LA1	🇯🇵 CO <-> 🇺🇸 BAGE LA2
Outbound	Outbound	Outbound	Outbound
Return	Return	Return	Return

🇯🇵 Lite <-> 🇺🇸 Misaka SEA	🇯🇵 Lite <-> 🇺🇸 Nube SJC	🇯🇵 Lite <-> 🇺🇸 BAGE LA1	🇯🇵 CO <-> 🇺🇸 BAGE LA2
Outbound	Outbound	Outbound	Outbound
Return	Return	Return	Return

8. Speedtest Multi-threadspeed test

curl -sL nws.sh | bash

JP2CO	JP2CO Lite

9. Summary

Compared with CO, CO Lite is currently mainly worse on Unicom. The broken SoftBank outbound route makes Unicom latency surge. In other respects the two are not very different, since outbound routing is the main product difference. Mainland return speeds are both quite capable, with different regions favoring one or the other. If you bought BL before, the value is very high; Telecom switching to 163 is also a highlight, though who knows when it will switch back. Even the previous three-network 4837 setup was already very cost-effective.

10. About the tests

The machines tested in this article, including all machines used for iPerf3 speed tests, were purchased at my own expense. Results may be time-sensitive.
Kernel parameters of the tested machines (/etc/sysctl.conf) are as follows

fs.file-max = 6815744
net.ipv4.tcp_no_metrics_save=1
net.ipv4.tcp_ecn=0
net.ipv4.tcp_frto=0
net.ipv4.tcp_mtu_probing=0
net.ipv4.tcp_rfc1337=0
net.ipv4.tcp_sack=1
net.ipv4.tcp_fack=1
net.ipv4.tcp_window_scaling=1
net.ipv4.tcp_adv_win_scale=1
net.ipv4.tcp_moderate_rcvbuf=1
net.core.rmem_max=33554432
net.core.wmem_max=33554432
net.ipv4.tcp_rmem=4096 87380 33554432
net.ipv4.tcp_wmem=4096 16384 33554432
net.ipv4.udp_rmem_min=8192
net.ipv4.udp_wmem_min=8192
net.ipv4.ip_forward=1
net.ipv4.conf.all.route_localnet=1
net.ipv4.conf.all.forwarding=1
net.ipv4.conf.default.forwarding=1
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1

11. Acknowledgements

Thanks to “Impart Speed Test“(@Kyoma) for providing public-interest speed-test service.