Although I previously tested these two RFCHOST Japan route machines on NS, now both CO and Lite have adjusted outbound routes, and I did not expect them to become this popular, so I tested them again. xhj015

Contents

1. Configuration Comparison
2. Evening Peak Return-to-China Speed Tests
3. Return Routes & Network Quality
4. Outbound Routes & TCP Ping
5. International Connectivity
6. IP Quality & Streaming Unlock
7. Performance Tests
8. Summary

1. Configuration Comparison

Plan 🇯🇵 RFCHOST JP2-CO-Micro 🇯🇵 RFCHOST JP2-CO-Balance-Lite
Location Japan, Tokyo Japan, Tokyo
CPU 1vCPU 1vCPU
RAM 1GB 1GB
Disk 10GB 10GB
Traffic 500GB(in+out) 400GB(in+out)
Return Telecom 163PP/Unicom 4837/Mobile CMI Telecom 163PP/Unicom 4837/Mobile CMI
Outbound Telecom 163PP/Unicom 4837/Mobile 4837 TelecomIIJ/UnicomSoftBank/MobileSoftBank
Network 1 x IPv4 1 x IPv4
Price Annual USD$49.9 Annual USD$39.9

Provider website: rfchost.com

These are the original configurations of the two models; mine was upgraded through the spin-wheel promo, so refer to the actual machine. xhj002

RFCHOST (domain registered on 2016-02-29) is an established VPS provider. It offers Tier 1 plans in Hong Kong, Japan, Singapore, and the United States, as well as China-optimized plans in Hong Kong, Japan, and the United States. Because of recent large discounts (a significant price cut plus a 40% off coupon), its Japan China-optimized plans have received a lot of exposure.

The RFCHOST JP1-CO-Balance annual plan launched on 2025-05-20. Its original route was three-network 4837 both ways, and traffic was only 300GB/month, later upgraded for free to 500GB/month. The machines were eventually migrated to the JP2 data center and the product line changed to JP2CO-Micro, while specs, traffic, and renewal price stayed the same. RFCHOST JP2-CO-Balance-Lite launched on 2025-06-30; its original route was three-network 4837 return with SoftBank outbound and 400GB/month traffic. Recently both were upgraded to the current routes, with further optimization both ways.

🔗 Quick Links


YABS Node Quality Mixed Benchmark nws.sh Streaming Unlock
[JP2CO] [JP2CO-Lite] [JP2CO] [JP2CO-Lite] [JP2CO] [JP2CO-Lite] [JP2CO] [JP2CO-Lite] [JP2CO] [JP2CO-Lite]

Looking GlassSpeed-test Address:[JP2CO] | [JP2CO-Lite]
Beijing/Shanghai/Guangzhou three-network real-time return latency - Probe: [JP2CO] | [JP2CO-Lite]

2. Evening Peak Direct Single-Thread Speed Tests

Test Method: single-thread TCP
Speed Test URL: https://speed.cloudflare.com
Latency Check URL: http://www.apple.com/library/test/success.html

Rather than only reading the review, you can also visit RFCHOST's official speed-test address https://rfchost.net/lookingGlass to get first-hand experience.

For China Telecom, both have very good speed, with much more bandwidth than typical machines. Latency is high for both. Although RFCHOST uses 163PP return for Telecom (a high-priority 163 direct route that can sometimes have lower latency than CN2) and is not affected by the Shanghai-Japan CN2 fault, CO's current Telecom 163PP outbound detours through scrubbing, causing high latency. Lite's Telecom outbound goes through IIJ, which is not an optimized route, so latency is also high.

For China Unicom, both speeds are also impressive, and CO and Lite are not far apart. In most cases CO has lower latency than Lite, but neither is in the first tier for latency.

China Mobile is more average. Shanghai can run very fast, but speeds to other provinces and cities are not as good as China Unicom or Telecom, though they are basically usable. China Mobile is too prone to QoS.

It can also be seen that because the return routes are the same, the speed difference between the two is not large.

China Telecom China Unicom China Mobile

Mainland China Upload Test

Click to expand
Test Method: iPerf3 TCP single-thread & one 10-second run
Test Time: 2026-01-25 19:00

CO has serious outbound upload limits, around 20Mbps, so it is not suitable for high-traffic domestic tunneling or live-streaming use. Lite does not limit upload speed, but its outbound route is SoftBank/IIJ, so latency, packet loss, and stability are not guaranteed.

Node 🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite
ShenzhenTelecom@1Gbps 23.3Mbps 639Mbps
QingdaoUnicom@1Gbps 19.3Mbps 1.05Gbps
GuangdongMobile@1Gbps 22.0Mbps 1.01Gbps

3. Return Routes & Network Quality

Click to expand

CO Telecom return uses 163PP direct, Unicom uses 10099->4837, and Mobile uses CMI.
Lite's return route is the same as CO.

🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite

4. Outbound Routes & TCP Ping

Click to expand

Three-Network Outbound Routes

CO Telecom outbound uses 163PP direct; Unicom and Mobile outbound use 4837->10099.
Lite Telecom outbound uses the backbone to IIJ, while Mobile and Unicom outbound use their respective backbones to SoftBank.

The familiar Sakura appears in traceroutes; is it really hard for Asia-Pacific China routes to avoid these providers? yct008

  • 🇯🇵 RFC JP2CO
Location China Telecom China Unicom China Mobile
Beijing
Shanghai
Guangzhou
  • 🇯🇵 RFC JP2CO-Lite
Location China Telecom China Unicom China Mobile
Beijing
Shanghai
Guangzhou

Three-Network TCP Ping

The result is somewhat counterintuitive: Lite's Unicom and Mobile SoftBank outbound routes have less packet loss and jitter than CO's optimized outbound routes. I am not sure whether this is related to the IP range. For Telecom, Lite's SoftBank outbound and CO's 163PP outbound are similar, both with some packet loss and jitter.

  • 🇯🇵 RFC JP2CO
China Telecom China Unicom China Mobile
  • 🇯🇵 RFC JP2CO-Lite
China Telecom China Unicom China Mobile

5. International Connectivity

Click to expand

The local bandwidth port is very large, and latency and speed to Hong Kong and Taiwan are excellent.
Latency to Seattle is relatively high because Seattle->Tokyo goes through NTT; if that matters, you can relay through a Japan GSL machine.

Web Latency

bash <(wget -qO- https://raw.githubusercontent.com/danger-dream/network-latency-tester/main/latency.sh)
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite

Route Tests

Test Site: bgp.tools
Test Time: 2026-01-26 13:00
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite

Own-node Speed & Latency Tests

Test Method: iPerf3 TCP single-thread & one 10-second run
Test Time: 2026-01-26 22:00
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite

Speedtest Multi-Thread Test

curl -sL nws.sh | bash
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite

6. IP Quality & Streaming Unlock

Click to expand

The measured IP quality is average, and CO's Google geolocation even went to China. However, RFCHOST has global unlock, so local streaming unlock should not be a big concern; cross-country unlock is just not very stable.

*Script test results are for reference only; actual results prevail.

bash <(curl -sL https://run.NodeQuality.com)
  • Before enabling global unlock
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite
  • After enabling global unlock (unlock region: Japan)
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite
bash <(curl -L -s check.unlock.media)
  • Before enabling global unlock
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite
  • After enabling global unlock (unlock region: Japan)
🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite

7. Performance Tests

Click to expand
bash <(curl -sL https://Check.Place) -H

Micro and Mini have only one core; Standard and Advance have two and four cores respectively. Single-core performance is acceptable.

🇯🇵 RFC JP2CO 🇯🇵 RFC JP2CO-Lite

8. Summary

Overall, both are very cost-effective route machines. China Unicom and Telecom users both have very good choices here, especially now that cheap Asia-Pacific route machines are struggling. China Mobile is also acceptable, but cannot escape QoS; before buying, it is best to test the Looking Glass from your own home broadband. If you need upload speed, want something cheaper, and can accept potentially more route fluctuation, Lite is fine; return speed is not much different from CO and sometimes trades blows. If you like speed tests, do not need upload, and accept paying a bit more for a better experience, CO is a safe choice. If you are new or do not know what to pick, choose CO.

9. About the Tests

Click to expand

The machines used in this test were purchased at my own expense; results may be time-sensitive.
Kernel parameters of the test 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

10. Acknowledgements

Click to expand

Thanks to "Impart Speed Test“(@Kyoma ) for proproviding the mainland China public-interest speed test service; thanks to itdog.cn for providing the free distributed probing service.