We needed occasional support sessions, not a subscription. We therefore self-hosted RustDesk Server OSS on an existing Riven Cloud Tokyo VPS while keeping the familiar remote-support workflow for the person receiving help.

Why self-host RustDesk?

Self-hosting gives the operator control of the server identity and relay path. RustDesk generates an Ed25519 key pair when hbbs first starts. The public key identifies and authenticates the self-hosted server to clients configured with that key. It is not a password, secret, or access-control list. Give clients only the public key and never expose the private id_ed25519 file.

RustDesk sessions are end-to-end encrypted. A relay carries encrypted session traffic rather than an unencrypted desktop stream. With self-hosting, even that encrypted relay traffic stays on infrastructure we control instead of passing through a third-party relay.

RustDesk Server OSS also has no membership tiers, device-count limits, or per-feature paywalls. It provides the core ID and relay services without the web console, account management, and other administrative features offered by RustDesk Server Pro.

Relay placement is another practical benefit. We can choose the location and carrier path instead of accepting whichever relay the vendor assigns. This matters when a direct peer-to-peer connection cannot be established and the desktop session must cross the relay in both directions.

SSH, WireGuard, and Tailscale are excellent tools for machines and users we administer. They were wrong for this case because the remote party was a non-technical third party. The workflow needed to remain: install the client, share the ID, and approve the session. Requiring a tunnel would have created a second support job before we could address the first one.

How do you install RustDesk Server OSS with Docker?

The official RustDesk Server OSS installation guide recommends Docker for most deployments. The method below follows that guide and the current Docker documentation for a portable Compose deployment.

Check the prerequisites

Use a Linux VPS with a public IPv4 address. Dual-stack IPv4 and IPv6 is preferred when both client networks support it. You also need sudo or root access and enough firewall control to expose the RustDesk ports.

A DNS hostname is optional but recommended. The examples use rustdesk.example.com; replace it with your own hostname. A public IP address also works, but a hostname is easier to move to another server later.

Install Docker and start the services

Create a working directory so that the Compose file and persistent server data stay together:

mkdir -p ~/rustdesk-server
cd ~/rustdesk-server

Install Docker with the convenience installer used by the official documentation. Operators who already have a working Docker Engine and Compose plugin can skip this command:

bash <(wget -qO- https://get.docker.com)

Download the official Compose file, then start both services:

wget https://rustdesk.com/oss.yml -O compose.yml
sudo docker compose up -d

At the time of writing, the live oss.yml starts hbbs and hbbr from rustdesk/rustdesk-server:latest. Both containers mount ./data:/root, use host networking, and restart with the unless-stopped policy.

Host networking means the processes listen directly on the VPS network stack. Check that both containers are running and inspect the hbbs startup output:

sudo docker compose ps
sudo docker compose logs --tail=100 hbbs

Open the firewall

The official guide gives this simple UFW example:

sudo ufw allow 21114:21119/tcp
sudo ufw allow 21116/udp

The range is broader than the minimum RustDesk Server OSS set. Port 21114/tcp serves the Pro web console and is not required by OSS. Port 21115/tcp is used for the NAT type test. Port 21116/tcp handles connections and TCP hole punching, while 21116/udp handles ID registration and heartbeat traffic. Port 21117/tcp carries relay sessions. Ports 21118/tcp and 21119/tcp support web clients and are optional when web-client access is unused.

Port 21116 must be allowed over both TCP and UDP. A tighter OSS policy can omit 21114/tcp and, when appropriate, the two web-client ports. Mirror the chosen rules in any cloud firewall or security group outside the VPS. If the service is reachable over IPv6, verify that UFW created matching IPv6 rules rather than checking only the IPv4 table.

Retrieve the public key safely

The downloaded Compose file mounts the host’s ./data directory at /root inside both containers. After the first start, the host-side public key is therefore normally ./data/id_ed25519.pub.

File layout can vary with the server version or deployment method. Find public-key files in the persistent directory if the expected path is absent:

sudo find ./data -maxdepth 2 -name '*.pub' -type f -print

Read the expected public key with:

sudo cat ./data/id_ed25519.pub

The hbbs log can also show the generated key and help diagnose a different data layout:

sudo docker compose logs hbbs

Copy only the content of id_ed25519.pub into client configuration. Never share, publish, or paste id_ed25519, which is the server’s private key. Back up the persistent data directory securely because replacing the private key changes the server identity expected by configured clients.

Configure the clients

On each RustDesk client, open Settings > Network and set:

• ID Server: rustdesk.example.com or your public IP address
• Key: the content of id_ed25519.pub
• Relay Server: leave blank
• API Server: leave blank

Both ends of the session need the self-hosted ID server and public key. hbbs advertises the associated hbbr relay automatically, so a separate relay value is unnecessary. The API field is for Pro features and remains blank for this OSS setup.

Verify a real client-to-client session

Test between two clients on different networks rather than stopping after the containers report healthy. Confirm that both clients receive IDs through the new server, connect, and can exchange screen updates, keyboard and mouse input, and clipboard content.

In our actual test, Linux and Windows clients completed a real relayed session. Screen, keyboard and mouse input, and clipboard all worked. Direct hole punching failed for that test, so hbbr relayed the session. One successful session is an operational check, not a controlled network benchmark, and we are not using it to claim a latency figure.

The official installation guide says CPU and memory requirements are minimal. It estimates roughly 30 KB/s to 3 MB/s for a relayed 1920×1080 session, depending on resolution and screen activity, with office work around 100 KB/s. These are broad upstream estimates, not capacity or performance guarantees. Size transfer allowance and monitoring for your own concurrency and usage pattern.

Why use a Tokyo VPS for support into mainland China?

A RustDesk relay is more of a network workload than a compute workload. Once the small CPU and memory requirement is met, adding vCPU does not repair a poor return path. Relay placement matters because a failed direct connection sends the interactive session through hbbr.

This is Riven Cloud’s own blog, and we sell the VPS used for this deployment. Our Tokyo network has carrier-specific paths for the three major mainland China access networks:

• China Telecom: CTGNet, formerly China Telecom CN2 GIA, AS23764 / AS4809
• China Unicom: CUP, China Unicom Premium, AS9929 / AS10099
• China Mobile: CMIN2, China Mobile International N2, AS58807

Our China-optimized routes explainer describes what those names mean and how to inspect the path. Operators should test from the networks that will actually use the service. The Tokyo Looking Glass provides a starting point for ping and traceroute checks, but testing from the client access network remains important.

Performance depends on the access carrier, province, last mile, time of day, and whether RustDesk establishes a direct connection. A direct connection may bypass the relay workload entirely. A relayed session takes the server path, but no single Tokyo test proves how every mainland China access line will behave.

When is self-hosting not worth it?

One-off users and operators unwilling to maintain updates, firewall policy, keys, and monitoring should use a hosted remote-support vendor. That fee buys less operational responsibility.

Self-hosting fits better when a suitable VPS already exists, support sessions recur, infrastructure control matters, or the workload needs a specific location and carrier path. The calculation should include server cost, transfer, and operator time rather than comparing only two monthly prices.

Test the Tokyo route from the networks that matter, then compare Riven Cloud VPS pricing with the subscription cost and maintenance burden being replaced.

The CA/Browser Forum approved Ballot SC-081v3, which sets a schedule for reducing public TLS certificate maximum validity periods. The ballot describes a reduction that starts in March 2026 and ends in March 2029 at 47 days. DigiCert’s explainer gives the operational dates in plain form: 200 days from March 15, 2026, 100 days from March 15, 2027, and 47 days from March 15, 2029.

Once certificate lifetimes keep shrinking, the choice gets less theoretical. Performance and architecture still matter. The first operational question is simpler: how much certificate, TLS, reload, and protocol work do you want humans to keep doing?

Manual certificate management is finished as a serious plan. You can renew a 47-day certificate by hand in theory, the same way you can run production backups by dragging files into a folder. The failure mode is obvious, and it will arrive at the worst time.

All version-sensitive claims below were checked on July 2, 2026. HTTP/3 and ACME support are still moving enough that dates matter.

The short answer

Caddy is the low-ops choice. It gives you automatic HTTPS, sensible TLS defaults, and HTTP/3. For a small team, a product site, a dashboard, or a containerized service, Caddy usually gets you to the right end state fastest.

Nginx is the control choice. It has the highest ceiling for reverse proxying, load balancing, traffic shaping, and careful tuning. Native ACME closes the old certificate gap, but Nginx still expects you to understand the config model. Fair trade, if you want the control.

Apache is the compatibility choice. Pick it for .htaccess, legacy modules, shared-hosting compatibility, or old WordPress and PHP workflows that expect per-directory overrides. If HTTP/3 matters now, Apache is the weak fit here.

Architecture decides the memory curve

Apache 2.4 is built around Multi-Processing Modules. The official Apache MPM documentation explains that Apache can use prefork, worker, or event, with only one MPM loaded at a time. prefork is process based, worker mixes processes and threads, and event is the modern default on most Unix-like systems.

Apache’s flexibility is useful, but it spreads the work around. You are choosing a process model, module set, virtual host structure, override behavior, and usually a PHP execution model.

Nginx uses a master process and worker processes. Its beginner guide says worker processes handle requests and that Nginx uses an event-based model with OS-dependent mechanisms to distribute work efficiently. That keeps connection handling cheap when the server is mostly moving bytes between clients and upstreams.

Caddy 2 is written in Go. The Caddy architecture docs describe it as a single static binary with zero external dependencies, and Caddy’s HTTP stack sits on Go’s concurrency model. Deployment is simple. Concurrency is good. Under extreme reverse-proxy load, Go runtime behavior, garbage collection, and fewer low-level tuning knobs can matter.

For a reverse proxy pushing very high concurrency and strict tail-latency targets, Nginx still has the sharper toolset.

HTTP/3 status in 2026

HTTP/3 runs over QUIC and UDP. Enabling it means the server must listen on UDP 443, the firewall must allow it, and the network path must pass QUIC cleanly.

Nginx has HTTP/3 support through ngx_http_v3_module. The current official docs say the module was introduced in 1.25.0 and still describe it as experimental support. That label is not a panic button. It is a reason to test your clients, CDN, firewall, kernel, and observability stack before you call the rollout done.

Caddy supports HTTP/3 by default. Its global options documentation lists the default HTTP protocols as h1 h2 h3, and automatic HTTPS is part of the normal site-address flow.

Apache is behind here. Apache’s public 2.4 module index lists mod_http2 for HTTP/2 and mod_proxy_http2 for proxying HTTP/2, but no HTTP/3 module. The mod_http2 page describes support for the HTTP/2 transport layer. As of July 2, 2026, Apache is a poor choice if HTTP/3 is a near-term requirement.

Certificate automation is the main event

The certificate lifetime schedule turns ACME from a nice-to-have into infrastructure. If renewals are boring and visible, 47-day certificates are manageable. If renewals depend on a wiki page and a tired person on a Friday, the system is already broken.

Caddy wins this section by design. Its automatic HTTPS docs say Caddy serves public DNS names over HTTPS using certificates from public ACME CAs such as Let’s Encrypt or ZeroSSL, keeps managed certificates renewed, and redirects HTTP to HTTPS automatically. If Caddy knows the public site name, it serves the site over HTTPS automatically. Issuance, renewal, redirects, OCSP behavior, and protocol defaults are part of the normal path.

Nginx caught up in 2025. It announced a preview release of ngx_http_acme_module on August 12, 2025. The announcement says the module provides directives for requesting, installing, and renewing certificates from Nginx configuration, and that it is a Rust-based dynamic module for both Nginx Open Source and NGINX One customers using NGINX Plus. The current module docs say ngx_http_acme_module implements ACMEv2, its source is on GitHub, and a prebuilt nginx-module-acme package exists since 1.29.0. N.WTF’s Debian and Ubuntu builds include the official module by default; its changelog records nginx-acme being added on November 29, 2025. Let’s Encrypt also covered the official module.

A practical Nginx ACME baseline starts with a persistent state directory. The module stores account data, certificates, and private keys there, so create it before reload and keep its permissions tight:

sudo mkdir -p /var/cache/nginx/letsencrypt

The Nginx configuration is longer than Caddy’s, but it now keeps ACME, HTTP/2, and HTTP/3 inside Nginx:

resolver 8.8.8.8:53 ipv6=off valid=5s;

acme_issuer letsencrypt {
    uri         https://acme-v02.api.letsencrypt.org/directory;
    contact     user@example.com;
    state_path  /var/cache/nginx/letsencrypt;
    accept_terms_of_service;
    ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
}

acme_shared_zone zone=ngx_acme_shared:1M;

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    location /.well-known/ {
        return 404;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;

    http2 on;

    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    add_header Alt-Svc 'h3=":$server_port"; ma=86400' always;
    add_header X-protocol $server_protocol always;

    server_name example.com;

    root /var/www/html;
    index index.html;

    ssl_protocols TLSv1.3;
    ssl_ecdh_curve X25519:prime256v1:secp384r1;
    ssl_prefer_server_ciphers off;

    acme_certificate letsencrypt;

    ssl_certificate $acme_certificate;
    ssl_certificate_key $acme_certificate_key;
    ssl_certificate_cache max=2;
}

Keep ssl_verify on for production. The official module has an ssl_verify off switch, but using it disables verification of the ACME server certificate; with the CA bundle above, the safer default is to verify.

The current docs list HTTP-01 and TLS-ALPN-01 as accepted challenge types. DNS-01 is not listed there. If you need wildcard certificates, verify that path before assuming native Nginx ACME covers it.

Apache can do ACME too. mod_md manages domains across virtual hosts and provides certificate provisioning via ACME. Its docs include examples with MDomain, ACME CA settings, challenge selection, renewal windows, and status integration.

Apache’s ACME problem is awareness and ceremony, not capability. You have to know mod_md exists, enable it, configure managed domains, understand virtual host interaction, and keep Apache’s TLS posture in order. In a 47-day certificate world, that is more human work than Caddy and a less direct workflow than modern Nginx.

Configuration difficulty is the visible symptom

Installation is routine in 2026. On Debian or Ubuntu, Apache and Nginx are package-manager basics. Caddy usually starts by adding the official repository, then it is also just a package install. The difference shows up in config.

Caddy can reverse proxy a public HTTPS site in three lines:

example.com {
    reverse_proxy 127.0.0.1:3000
}

That gives you HTTPS automation and, by default, HTTP/1.1, HTTP/2, and HTTP/3. Caddy also has a native JSON configuration model and an admin API. The API docs say Caddy is configured through an HTTP administration endpoint, defaults to localhost:2019, and can load new config with zero downtime while rolling back failed loads.

Nginx is manageable, but explicit. Once HTTP/3 is included, the server block is no longer tiny:

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;

    # HTTP/3 over QUIC
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    # HTTP/2
    http2 on;

    server_name example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    add_header Alt-Svc 'h3=":$server_port"; ma=86400' always;
    add_header X-protocol $server_protocol always;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Readable, widely documented, easy to lint. The Nginx bargain is simple: you get a precise reverse proxy, but you own each decision unless a module or platform owns it for you.

Apache has the most moving parts:

MDomain example.com
MDCertificateAgreement accepted

<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

<VirtualHost *:443>
    ServerName example.com

    SSLEngine on
    Protocols h2 http/1.1 acme-tls/1

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/
</VirtualHost>

Apache’s power is real, but the surface area is larger. httpd.conf, virtual host inheritance, MPM choice, .htaccess, mod_ssl, mod_proxy, mod_md, and per-directory behavior all become part of the job.

Performance, without fake benchmark theater

Nginx is still the ceiling for high-concurrency reverse proxying. Its event-driven model, mature upstream handling, low memory footprint, and tuning surface are why it remains common at the edge.

Old comparison posts often underrate Caddy. Static file serving and ordinary reverse proxy workloads are fine. For most product sites, APIs, admin panels, and internal tools, app latency and database latency will dominate the difference.

The Caddy caveat lives at the far end: very high concurrency, strict memory budgets, and tail latency under sustained proxy load. Go’s runtime and garbage collector are part of the operating model. Nginx gives you more control when that level of tuning matters.

Apache can perform well with the event MPM, but legacy shape still matters. The prefork model remains common in older PHP stacks and shared-hosting environments, and prefork is expensive per connection. .htaccess can also force per-directory checks at request time. Useful, but not free.

Market share should inform your risk model, not decide the winner. W3Techs’ web server survey in late June 2026 showed Nginx at 31.8%, Apache at 23.2%, and Caddy at 0.2% of websites whose web server W3Techs knows. Nginx and Apache have deeper operational folklore. Caddy has less market share, but its defaults remove work that older stacks still hand to the operator.

Apache’s real moat is .htaccess

Apache still owns one use case the others do not replace cleanly: .htaccess.

For shared hosting, that matters. A provider can let customers change rewrite rules, authentication, redirects, cache headers, PHP behavior, and per-directory settings without main server config access. WordPress, legacy PHP, and control-panel hosting grew around that model.

The same mechanism has a cost. .htaccess moves configuration out of one central reviewable file and into the document tree. Apache may need to check directories for override files on requests.

If you run a modern VPS, container, or single-tenant app server, .htaccess is usually a liability. If you run a shared host or a legacy app that expects it, it may be the whole reason Apache is still the right answer.

Nginx has a community split to watch

Nginx is still a strong default. Its ecosystem is less unified than it used to be.

F5 acquired NGINX in 2019, and the boundary between open source Nginx, NGINX Plus, and NGINX One remains a recurring operator discussion. In February 2024, Maxim Dounin started freenginx, whose site describes it as an effort to preserve free and open Nginx development. Angie is another Nginx-family project; its own site says the open source Angie server was created as a fork of Nginx. In 2026, “Nginx” might mean open source Nginx, NGINX Plus, freenginx, Angie, OpenResty, N.WTF packages, or a vendor platform built around Nginx semantics.

Other servers worth knowing

LiteSpeed and OpenLiteSpeed deserve a look for WordPress-heavy deployments, especially where LSCache is central. HAProxy is excellent when the job is load balancing, TLS termination, traffic routing, health checks, and proxy behavior. Traefik fits container-native routing well when your world is Docker labels, Kubernetes ingress, service discovery, and automatic Let’s Encrypt for many short-lived services. They are narrower picks than Apache, Nginx, and Caddy for a general-purpose VPS web server.

Decision guide

Choose Caddy when:

• you want HTTPS and HTTP/3 as defaults
• your team is small and ops time is scarce
• you deploy services frequently and like API-driven reloads
• you value simple config over maximum tuning depth

Choose Nginx when:

• you run high-traffic reverse proxy workloads
• you need precise upstream, caching, buffering, or rate-limit behavior
• your team already knows Nginx well
• you want native ACME but still prefer explicit server configuration

Choose Apache when:

• .htaccess support is required
• you are operating a shared-hosting or legacy PHP environment
• the application depends on Apache modules or old deployment assumptions
• HTTP/3 can wait

For a new 2026 VPS deployment, my default is Caddy for simple apps, Nginx for serious proxy and tuning work, and Apache when Apache compatibility is part of the requirement.

VPS control matters for HTTP/3

HTTP/3 needs UDP 443. Certificate automation needs reliable inbound validation or correct DNS automation. Serious web-server tuning needs root access, firewall control, kernel and sysctl visibility, logs, and a network where you can test the actual path.

A VPS is cleaner than shared hosting for this. On Riven Cloud, every plan is an unmanaged KVM VPS with full root access, a dedicated IPv4 address, a /64 IPv6 block, NVMe SSD storage, daily backups, and a 1 Gbps network port. If you are choosing a web server for users in mainland China, test the route from Tokyo or Singapore first, then compare plans on the pricing page.

Conclusion

The 2026 web server choice starts with automation. Caddy gives you the shortest path to a correct modern HTTPS setup. Nginx gives you the highest ceiling when traffic shape and proxy control matter. Apache remains the compatibility king for .htaccess, shared hosting, and old module ecosystems, but HTTP/3 absence and heavier configuration make it harder to justify for new deployments.

The fix is mostly order. Add and test an SSH key first. Then disable password login, move the listener only after the new port is open, configure fail2ban, and close whatever you no longer need. Key-only SSH does the serious work. A custom port makes the logs quieter. fail2ban blocks noisy clients, but it does not make weak authentication safe.

Use one rule for the whole job: build the new entrance before closing the old one. Do not disable a login method, restart SSH, or remove a firewall rule until the replacement path works from a new terminal.

This is written for people running an unmanaged Linux VPS. If you are still deciding whether root access is worth the operational work, read VPS vs shared hosting first.

Before you start: don’t lock yourself out

Keep one working SSH session open the whole time. Do not close it just because the last command succeeded. SSH restarts usually leave existing sessions alone, and that terminal is your way back in if the next login test fails.

Run the OpenSSH server config test before every restart:

sudo sshd -t

The -t flag makes sshd check the configuration and keys, then exit without starting a new daemon, as documented in the OpenSSH sshd manual. If it prints an error, fix that first.

After each change, open a second terminal and log in again. Move on only after the new session works.

The service name depends on the distro:

# Debian and Ubuntu
sudo systemctl restart ssh

# AlmaLinux, Rocky Linux, and CentOS Stream
sudo systemctl restart sshd

Step 1: generate an SSH key and add it first

Start with the key because every later step depends on key login already working. OpenSSH supports several key types through ssh-keygen; for a normal modern server, Ed25519 is a sensible default. Use RSA 4096 only when an older server or client cannot use Ed25519. The ssh-keygen manual documents both key types.

On macOS or Linux:

ssh-keygen -t ed25519 -C "you@host"

The private key is usually saved as ~/.ssh/id_ed25519. The public key is ~/.ssh/id_ed25519.pub.

On Windows, use the built-in OpenSSH client from PowerShell:

ssh-keygen -t ed25519 -C "you@host"

PuTTY users can generate the key with PuTTYgen, then export the public key in OpenSSH format. If you log in with PuTTY, keep the private key in PuTTY’s format. If you log in from Terminal, PowerShell, or WSL, keep the private key in OpenSSH format.

Set a passphrase when ssh-keygen asks. It protects the private key if your laptop is stolen or a backup leaks. ssh-agent keeps the key usable without making you type the passphrase for every login:

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

On Windows PowerShell:

Start-Service ssh-agent
ssh-add $env:USERPROFILE\.ssh\id_ed25519

For a new Riven Cloud server, add the key before you install the OS.

Option 1: generate the key locally. In the Riven Cloud control panel, go to SSH keys, click Add Key, paste the contents of your .pub file, give it a clear name, and select it during OS install or reinstall.

Option 2: generate the key in the control panel. Go to SSH key > Add Key > Generate Key Pair, download the private key, and store it somewhere safe. Choose OpenSSH format for Terminal or PowerShell, or PuTTY format for PuTTY on Windows. Select that key when you install the server.

For an already-running server where password login still works, push the public key with ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub root@SERVER_IP

Test the key from a new terminal:

ssh -i ~/.ssh/id_ed25519 root@SERVER_IP

That login must work before you continue. If it fails, stop here and check the key path, username, public key, file permissions, or control panel selection. Leave password login alone until key login works.

Step 2: disable password login and lock down root

Password login is what turns random SSH scans into a guessing attack. Once key login works, disable password authentication and keyboard-interactive authentication. For this pass, keep root key login available with PermitRootLogin prohibit-password: root cannot use a password, but a valid key still works. The options are documented in sshd_config(5).

Create a drop-in file:

sudo install -d -m 755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/10-hardening.conf > /dev/null <<'EOF'
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin prohibit-password
EOF

Most current Debian, Ubuntu, AlmaLinux, Rocky Linux, and CentOS Stream images include /etc/ssh/sshd_config.d/*.conf from the main sshd_config. If your image is unusual, check the main file for this line:

Include /etc/ssh/sshd_config.d/*.conf

Validate first:

sudo sshd -t

Restart SSH:

# Debian and Ubuntu
sudo systemctl restart ssh

# AlmaLinux, Rocky Linux, and CentOS Stream
sudo systemctl restart sshd

Open a new terminal and test key login again:

ssh -i ~/.ssh/id_ed25519 root@SERVER_IP

Then confirm password-only login is refused from a new terminal:

ssh -o PubkeyAuthentication=no -o IdentitiesOnly=yes -o PreferredAuthentications=keyboard-interactive,password root@SERVER_IP

The server should reject the attempt without showing a password prompt. If key login still works and that password-only attempt fails, the biggest SSH hardening win is already done.

A non-root sudo user plus PermitRootLogin no is a stronger long-term setup, but do it only after that user has been tested. This guide keeps it optional because this is where people lock themselves out. If you make that change, create the sudo user, add its key, test sudo, then disable root login.

Step 3: change the SSH port for noise reduction

Moving SSH away from port 22 is housekeeping. It does not make SSH stronger, and it will not save a server that still accepts weak passwords. It mainly cuts down hits from scanners that only try the default port. Do it after key-only login works, and treat it as log cleanup.

This example uses port 2222. If you choose another port, use the same value in SSH, the firewall, and fail2ban.

Open the new port in the firewall before you restart SSH.

On AlmaLinux, Rocky Linux, and CentOS Stream, firewalld is commonly enabled on VPS templates and new inbound ports are closed by default. Add 2222/tcp first:

sudo firewall-cmd --permanent --add-port=2222/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

The firewall-cmd syntax is documented in the firewalld command manual.

On Ubuntu or Debian, UFW may or may not be enabled. Check before you add rules:

sudo ufw status

If UFW is active, allow the new port:

sudo ufw allow 2222/tcp
sudo ufw status

The Ubuntu ufw manual documents allow, delete, and status commands.

Now change the SSH listener. On most servers, use a temporary dual-port drop-in so port 22 stays available while you test port 2222:

sudo tee /etc/ssh/sshd_config.d/20-port.conf > /dev/null <<'EOF'
Port 22
Port 2222
EOF

Validate and restart:

sudo sshd -t

# Debian and Ubuntu
sudo systemctl restart ssh

# AlmaLinux, Rocky Linux, and CentOS Stream
sudo systemctl restart sshd

Open a new terminal and test the new port:

ssh -p 2222 -i ~/.ssh/id_ed25519 root@SERVER_IP

Remove port 22 from the SSH listener only after port 2222 works:

sudo tee /etc/ssh/sshd_config.d/20-port.conf > /dev/null <<'EOF'
Port 2222
EOF
sudo sshd -t

Restart SSH again with the correct service name for your distro. Then open one more new session on port 2222.

Ubuntu and Debian: check ssh.socket

Some Debian or Ubuntu systems use ssh.socket. When socket activation is active, systemd owns the listening socket, so the Port line in sshd_config may not control the initial listener. Check it:

systemctl status ssh.socket

If it is active and listening, override the socket instead of relying only on 20-port.conf:

sudo systemctl edit ssh.socket

Use both ports for the first test:

[Socket]
ListenStream=
ListenStream=22
ListenStream=2222

Then validate SSH config, reload systemd, and restart the socket:

sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

After ssh -p 2222 root@SERVER_IP works from a new terminal, edit the socket again and leave only this listener:

[Socket]
ListenStream=
ListenStream=2222

The ListenStream behavior comes from the systemd.socket documentation. Keep the order boring: add the new listener, test it, then remove the old listener.

SELinux note

Riven Cloud default Linux templates ship with SELinux disabled, so those templates do not need an SELinux port change.

If you enabled SELinux yourself on a RHEL-family server, allow the new SSH port before restart:

sudo dnf install policycoreutils-python-utils
sudo semanage port -a -t ssh_port_t -p tcp 2222

The semanage port command is documented in the semanage-port manual. Do not run it unless SELinux is actually enabled.

Once you can log in on port 2222, remove port 22 from the firewall.

For firewalld, the default SSH opening is usually the ssh service, not a raw port rule:

sudo firewall-cmd --permanent --remove-service=ssh
sudo firewall-cmd --permanent --remove-port=22/tcp
sudo firewall-cmd --reload

For UFW:

sudo ufw delete allow 22/tcp
sudo ufw delete allow OpenSSH
sudo ufw status

Run the delete command that matches what your firewall actually shows. Never remove port 22 before a new session on port 2222 works.

Step 4: stop brute force with fail2ban

fail2ban is useful after SSH authentication is already sane. Riven Cloud’s default Linux templates ship with fail2ban preinstalled. Verify it anyway:

sudo fail2ban-client --version
sudo fail2ban-client status sshd
sudo systemctl status fail2ban

If it is missing on a custom image, install it:

# Debian and Ubuntu
sudo apt update
sudo apt install fail2ban

# AlmaLinux, Rocky Linux, and CentOS Stream
sudo dnf install epel-release
sudo dnf install fail2ban

Put local overrides under /etc/fail2ban/jail.d/. Do not edit jail.conf directly; fail2ban’s upstream configuration is meant to be overridden locally, as shown by its default jail configuration.

sudo tee /etc/fail2ban/jail.d/ssh.conf > /dev/null <<'EOF'
[sshd]
enabled = true
port = 2222
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h
EOF

The port value must match the port from Step 3. If fail2ban watches port 22 while SSH listens on 2222, the jail is watching the wrong place.

Modern Debian, Ubuntu, AlmaLinux, Rocky Linux, and CentOS Stream systems normally log SSH authentication through the systemd journal, so backend = systemd is a good default. If your image writes only to traditional log files, use a log file backend instead.

Enable and start fail2ban:

sudo systemctl enable --now fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd

The sshd status output shows the jail, current failures, and banned IP addresses. With key-only auth in place, brute force attempts cannot log in by guessing a password. fail2ban still helps by blocking noisy scanners and keeping abusive clients from hitting your logs all day.

Step 5: tighten the firewall and extra SSH knobs

After SSH is stable on the new port, keep the firewall plain. Deny inbound traffic by default, then open only what the server actually serves.

For a web server, that often means SSH plus HTTP and HTTPS:

# firewalld
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

# UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

RHEL-family VPS templates are a useful model here: with firewalld enabled, SSH is allowed and random ports are closed. Keep that habit. Add a port when a service needs it, and remove the port when the service is gone.

Do not mix SSH cleanup with unrelated performance work. If a site feels slow after hardening, diagnose that separately with a page-load and server check such as why is my website slow.

A few optional SSH settings can make abuse less noisy:

MaxAuthTries 3
LoginGraceTime 30
AllowUsers deploy admin
# or:
# AllowGroups ssh-users

Use AllowUsers or AllowGroups only after the named user or group has been tested in a new session. The same rule still applies: test the new path before closing the old one.

What actually protects you when you secure SSH on a VPS

Do not treat every control as equal. They are not doing the same job.

1. Key-only authentication with password login disabled removes password guessing from the attack path.
2. A minimal firewall and a non-root sudo user reduce exposure and limit blast radius.
3. fail2ban cuts log noise and blocks abusive scanners.
4. Changing the SSH port reduces noise, not risk by itself.

Treat the port change as cleanup, not the main defense. A server on port 2222 with password login enabled is still a weak SSH server. A server on port 22 with passwords disabled and strong keys is already much harder to brute force.

Conclusion

The safe order is simple: add and test the key, disable passwords, open and test the new port, configure fail2ban, then remove anything you no longer need.

Riven Cloud’s Linux templates ship with fail2ban preinstalled, and the control panel can add SSH keys during deployment. If you need an unmanaged KVM VPS with root access, daily backups, and Tokyo or Singapore locations, you can view VPS plans.

The real tradeoff is control versus convenience.

Shared hosting gives you a prepared environment. You upload a site, click around a control panel, and let the provider handle most of the server work. A VPS gives you a server-like environment with root access. You decide what runs, how it is configured, and how it is maintained.

Neither model is automatically better. A portfolio site, small WordPress site, or local business page may be happier on shared hosting for years. A custom app, API, bot, database-backed service, or traffic-heavy site may become awkward on shared hosting quickly. The difference between VPS and shared hosting is less about status and more about your stage, skill level, and tolerance for operations work.

What shared hosting and VPS actually are

The simplest analogy is housing.

Shared hosting is like renting a room in a shared apartment. The kitchen, utilities, locks, and building rules are handled for you. You get a small private area, but the building owner decides what appliances are allowed, how noisy the neighbors can be, and what you can change.

A VPS is closer to having your own small house. The land still belongs to a larger provider, but your environment is isolated. You decide what to install, how to wire the rooms, and when to renovate. You also deal with the consequences when something leaks at 3am.

Underneath the analogy, shared hosting places many customer sites inside a provider-managed environment. CPU, memory, disk, web server configuration, PHP versions, mail handling, SSL tooling, backups, and control panel behavior are mostly standardized.

A VPS uses virtualization to give you an isolated operating system instance. You usually get a fixed amount of vCPU, RAM, disk, transfer, and network access. The provider owns the physical host and network. You own the software stack inside your virtual server.

Shared hosting: strengths and limits

Shared hosting is popular because it removes friction.

For a simple site, that matters. You do not need to install a web server, configure PHP-FPM, set up a firewall, harden SSH, schedule backups, or think about unattended security upgrades. The provider gives you a panel, a file manager or SFTP access, database creation tools, DNS helpers, SSL buttons, and often one-click installers.

That model is a good fit for many sites:

• static HTML/CSS pages
• small WordPress sites
• basic PHP apps
• landing pages
• small business sites
• hobby projects where uptime is useful but not mission critical

The best part is not the low price. It is the low mental load. You can build the site and avoid becoming the server administrator.

The limits are real, though. Many shared hosts do not provide shell access, or they provide a restricted shell that is not useful for serious deployment work. The stack is usually centered on PHP, static files, MySQL or MariaDB, and a provider-approved control panel. If your app needs Node.js workers, Python services, background queues, custom daemons, Docker, Redis, PostgreSQL, or long-running jobs, shared hosting may fight you.

Resource limits can also be opaque. A plan may advertise generous storage or transfer while enforcing CPU seconds, process counts, memory caps, inode limits, database query limits, cron frequency limits, or request throttles elsewhere. Those caps are not always bad. They protect the shared platform. They also mean your site can hit a wall without an obvious upgrade path.

Noisy neighbors are the other classic problem. Since many sites share the same underlying platform, another customer can affect performance if isolation is weak or the node is overloaded. Good shared hosts manage this carefully. Cheap shared hosts sometimes do not.

Shared hosting also tends to create lock-in around the panel and workflow. You may get used to provider-specific backup tools, staging tools, mailboxes, SSL buttons, and file deployment patterns. Moving later can take more work than expected.

VPS: strengths and limits

A VPS gives you control first.

With root access, you can install the stack your app actually needs: Nginx or Apache, Caddy, Node.js, Python, Go binaries, PHP, PostgreSQL, MySQL, Redis, Docker, queue workers, search tools, observability agents, cron jobs, private APIs, reverse proxies, VPN services, and internal tools.

That flexibility matters when the workload is no longer a plain website. A dashboard with background imports, a bot that listens all day, a webhook receiver, a small SaaS app, a staging server, or a private API all fit a VPS better than a restricted shared account.

Resources are usually more predictable. If the plan says 2 vCPU and 4 GB RAM, you can reason about capacity in a way that is harder on shared hosting. Virtualization is still shared at the physical host level, and providers vary, but the boundary is clearer. You can watch CPU, RAM, disk I/O, network use, and process behavior yourself.

Scaling is also more direct. You can move from a smaller VPS to a larger one, add a cache, split a database, move static assets to a CDN, run multiple services, or tune the web server for your workload. The path is not always one click, but it is usually under your control.

Dedicated IP addressing is another practical difference. A VPS often includes its own IPv4 address and IPv6 allocation. That can help with mail reputation separation, firewall allowlists, reverse proxy rules, custom SSL/network setups, and avoiding unrelated customers on the same address. It is not an automatic SEO boost. Search engines care more about crawlability, content, performance, and abuse signals than whether you bought a dedicated IP. Still, an address you control can make operations cleaner.

The limits are just as important.

With a VPS, security and operations become your job unless you pay for managed service. Someone has to patch the OS, lock down SSH, configure the firewall, rotate keys, monitor disk space, set up backups, renew certificates, tune the database, and recover from mistakes. If the server dies at 3am, the provider can usually tell you whether the VPS is powered on. It may not debug your Nginx config.

The “not optimally configured” point cuts both ways. An expert can tune a VPS better than a shared host’s generic environment. A novice can make a VPS slower, less secure, and less reliable than decent shared hosting. VPS value depends on the operator’s skill.

VPS vs shared hosting comparison

The cost myth

Shared hosting is not always cheaper.

At the very low end, shared hosting wins on price. A small static site or basic WordPress install does not need a dedicated server environment, and paying more for control you will not use is wasteful.

The math changes when a site needs a little more resource. A better shared plan with higher CPU limits, more processes, staging, backups, malware scanning, and premium support can approach or exceed the monthly price of a modest VPS. At that point, the difference is not simply “cheap versus expensive.” It is “managed convenience versus control.”

Shared hosting bundles operations into the price. A VPS unbundles it. If you can run the server well, the VPS may give you more usable capacity per dollar. If you need someone else to manage everything, shared hosting or managed hosting may be the better value even at a higher sticker price.

The blurred middle

The line is not as clean as it used to be. Managed VPS plans, container platforms, PaaS products, and serverless hosting all borrow pieces from both models. They can be the right answer, but they are separate decisions. For this comparison, the useful split is still simple: shared hosting sells convenience; VPS sells control.

How to choose

Start with operations skill.

If you cannot SSH into a server, read logs, patch packages, and recover from a broken config, shared hosting is probably the safer first choice. That is not an insult. It means your time is better spent on the site, product, or content. If you can handle Linux basics, or you have someone who can, a VPS becomes realistic.

Next, look at the app type.

A plain PHP site, brochure site, small WordPress install, or static site can run happily on shared hosting. A Node.js app, Python API, Go service, Dockerized app, long-running bot, queue worker, custom database setup, or private tool usually points toward a VPS.

Then check traffic and resource behavior.

Light traffic with predictable pages is a shared hosting sweet spot. Traffic spikes, slow admin pages, heavy plugins, import jobs, expensive database queries, or repeated “resource limit reached” messages are signs that the shared environment is becoming the constraint. Before blaming the host, measure the layer that is slow. The guide on why is my website slow is a useful companion here because it separates hosting problems from app, payload, DNS, and rendering problems.

Finally, ask whether you need to run things beyond the website.

Email processing, bots, background jobs, API workers, WebSocket services, reverse proxies, VPN endpoints, analytics collectors, cron-heavy imports, and staging environments all push you toward VPS hosting. Shared hosting is strongest when the workload is a website. A VPS is stronger when the workload is a small system.

When it is time to move to a VPS

Move to a VPS when the shared hosting tradeoff stops helping.

Common upgrade signals are straightforward:

• you keep hitting CPU, memory, process, inode, or database limits
• performance changes even when your own site has not changed
• you need shell access for deployment or debugging
• your app needs non-PHP software, background services, workers, or containers
• you want a dedicated IP address or IPv6 allocation for cleaner network operations
• traffic has grown enough that predictable resources matter
• you need a staging or internal service beside the public site
• the shared host’s panel is now shaping your architecture more than your app needs

If the problem is performance, confirm the bottleneck first. The answer to “should I switch to a VPS” is yes only when shared hosting is the layer holding you back, or when your workload no longer fits the shared model.

When you reach that point, getting a VPS is the cleaner path. Riven Cloud is a solid option if you want a KVM VPS with a dedicated IPv4 address, a /64 IPv6 block, NVMe SSD storage, and a choice of Tokyo or Singapore node locations, and you can view VPS plans when you are ready to move.

Conclusion

There is no absolute winner in VPS vs shared hosting.

Shared hosting is the better fit when convenience matters more than control. It keeps server work out of the way and gives many small sites exactly what they need. VPS hosting is the better fit when the application needs root access, predictable resources, custom software, background services, or a cleaner scaling path.

Match the hosting model to the stage of the project. A simple site can stay shared for a long time. A growing project usually trends toward a VPS because control starts to matter more than convenience.

It is also a common way to waste a week.

A page load crosses several layers before a visitor can use the page: DNS, connection setup, TLS, server processing, content transfer, caching, and browser rendering. Slowness can live in any one of them. If the page is slow because of a 4 MB image, a blocking JavaScript bundle, or an uncached database query, moving the same site may change nothing.

The useful question is not “is my hosting slow?” The useful question is which layer is slow. Diagnose a slow website by isolating that layer first.

Mental model: the request lifecycle

A browser does not load a page in one step. It walks through a chain of work:

• DNS resolution: the browser asks where the hostname points. Slow authoritative DNS, broken records, or bad TTL choices can delay the start.
• TCP and TLS handshake: the browser opens a connection and negotiates encryption. Distance, routing, packet loss, old protocol support, and certificate setup can all show up here.
• Server processing: the web server, application runtime, database, and upstream APIs produce the response. This is where slow TTFB often becomes visible.
• Content download: HTML, images, CSS, JavaScript, fonts, and API responses move over the network. Large payloads and missing compression hurt here.
• Browser rendering: the browser parses, styles, lays out, paints, and runs JavaScript. A fast server cannot save a front end that blocks the main thread.

Diagram placeholder: request lifecycle from browser to DNS resolver, TCP/TLS, web server, application/database, content download, and browser rendering.

Why is my website slow? Measure before guessing

Start with a waterfall, not a score. Chrome DevTools documents the Network panel and its request timing view in its Network reference. Use it to separate waiting time, download time, and blocked rendering resources.

PageSpeed Insights and WebPageTest are useful, but read the waterfall before debating the score. The number at the top is a summary. The waterfall is the evidence.

Screenshot placeholder: DevTools Network waterfall showing DNS, initial connection, TLS, waiting for server response, content download, and render-blocking CSS or JavaScript.

Use the command line as a second view. curl exposes timing variables such as time_namelookup, time_connect, time_appconnect, time_starttransfer, and time_total in its write-out documentation.

curl -o /dev/null -sS -w 'dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download} http=%{http_code} proto=%{http_version}\n' https://example.com/

Those times are cumulative from the start of the transfer. To estimate stage cost, subtract the previous stage. For example, TLS cost is roughly time_appconnect - time_connect, and server wait plus request time is roughly time_starttransfer - time_appconnect for HTTPS.

Then run the same test against a tiny static file and a dynamic page:

curl -o /dev/null -sS -w 'ttfb=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download}\n' https://example.com/favicon.ico
curl -o /dev/null -sS -w 'ttfb=%{time_starttransfer}s total=%{time_total}s bytes=%{size_download}\n' 'https://example.com/?probe=1'

That comparison is the fastest split in the whole investigation. If the static file has low TTFB but the dynamic page has high TTFB, your host may be fine and the app is probably slow. If both are slow from several networks, look harder at the host, origin network, CDN, or routing.

Add basic path checks:

ping -c 20 example.com
traceroute example.com
mtr -rwzc 100 example.com

Use MTR from the visitor region when possible. A test from your laptop only proves the path from your laptop.

Layer-by-layer diagnosis

DNS resolution

Symptom: The page pauses before any connection starts. DevTools shows a long DNS phase, or curl reports high time_namelookup.

How to test: Check authoritative records and resolver behavior:

dig example.com A +stats
dig example.com AAAA +stats
dig NS example.com +short
dig SOA example.com +short
dig +trace example.com

If one resolver is slow but another is normal, the problem may sit with a resolver path rather than your authoritative DNS. If authoritative nameservers are slow, misconfigured, or inconsistent, fix the DNS provider or registrar setup first.

Verdict: Usually not the host. It is often the registrar, DNS provider, nameserver configuration, or resolver path. The host is involved only when it also runs your authoritative DNS.

Connection and TLS

Symptom: DNS finishes quickly, but the connection or TLS phase is long. Visitors far from the server complain more than visitors near the server.

How to test: Compare TCP, TLS, and protocol support:

curl -o /dev/null -sS -w 'tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s proto=%{http_version}\n' https://example.com/
curl -I --http2 https://example.com/
curl -I --http3-only https://example.com/

The last command requires a curl build with HTTP/3 support. If it fails locally, use browser DevTools or an external test. MDN’s HTTP evolution guide summarizes how HTTP/2 multiplexing and HTTP/3 over QUIC change connection behavior.

TLS overhead is rarely the whole problem on a warm connection, but repeated cold connections from distant regions add up. Certificate errors, missing session reuse, no HTTP/2, no HTTP/3, and no edge cache can make this layer worse than it should. If you are changing certificate configuration, verify the certificate chain, renewal path, redirects, and protocol support before blaming the host.

Verdict: Mixed. Geographic distance is a node location problem. Routing quality and packet loss can be host-related. Certificate configuration and protocol support may be your web server or CDN configuration.

Server response and TTFB

Symptom: DNS, TCP, and TLS look reasonable, but time_starttransfer is high. DevTools shows a long “waiting for server response” phase. Users see a blank page before the first byte arrives.

How to test: Compare static TTFB with dynamic TTFB from the same client:

curl -o /dev/null -sS -H 'Cache-Control: no-cache' -w 'static_ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://example.com/favicon.ico
curl -o /dev/null -sS -H 'Cache-Control: no-cache' -w 'dynamic_ttfb=%{time_starttransfer}s total=%{time_total}s\n' 'https://example.com/?uncached=1'

If both are slow, check the server itself:

uptime
free -m
vmstat 1 10
top -bn1 | sed -n '1,5p'

On a VPS, sustained CPU steal while the instance is lightly loaded is a red flag. It means the hypervisor is not giving your virtual CPU the time it asked for. RAM pressure, swap churn, and disk wait can create the same user-visible symptom.

If the static file is fast and the dynamic page is slow, move up the stack. Check application logs, PHP-FPM status, slow database queries, cache misses, upstream API latency, and queue workers. In a WordPress, PHP, or custom app, one uncached page or slow SQL query can make the host look guilty.

Verdict: Could be host or app. High TTFB on a tiny static file points toward host, origin network, CDN miss behavior, or web server configuration. High TTFB only on dynamic pages usually points to application code, database work, PHP/runtime limits, or cache misses.

Payload size

Symptom: TTFB is fine, but total load time is high. The waterfall shows large images, fonts, JavaScript bundles, CSS, or API responses taking most of the time.

How to test: Look at transferred bytes in DevTools and compare compressed responses:

curl -sS -o /dev/null -D - -H 'Accept-Encoding: br,gzip' https://example.com/
curl -o /dev/null -sS -w 'bytes=%{size_download} total=%{time_total}s\n' https://example.com/

Check for content-encoding: br or content-encoding: gzip on compressible text responses. MDN’s HTTP compression guide explains Accept-Encoding and response compression. For images, inspect dimensions and formats. A 3000 px image squeezed into a 360 px mobile slot is a content problem, not a VPS problem.

Verdict: Not the host. Hosting can affect throughput, but unoptimized images, excessive JavaScript, unused CSS, and missing compression belong to the site build and delivery configuration.

Caching and CDN

Symptom: The first request is slow, repeat requests are faster, or every page hit regenerates dynamic content. Global visitors see inconsistent results.

How to test: Inspect cache headers and repeat requests:

curl -I https://example.com/
curl -I https://example.com/assets/app.css
curl -o /dev/null -sS -w 'ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://example.com/
curl -o /dev/null -sS -w 'ttfb=%{time_starttransfer}s total=%{time_total}s\n' https://example.com/

Look for cache-control, etag, last-modified, age, vary, and CDN-specific headers such as x-cache. A page cache can turn dynamic generation into a quick static response. A CDN can move static assets closer to users, but cache-busting query strings, no-store headers, and logged-in cookies can bypass it.

Verdict: Host-adjacent and configuration-driven. The host may provide a cache or CDN integration, but the policy is usually yours: what can be cached, for how long, and whether dynamic pages are safe to cache.

Front-end rendering

Symptom: HTML arrives quickly, but the page still feels slow. DevTools shows long main-thread tasks, render-blocking CSS, large JavaScript execution time, layout shifts, or late-loading fonts.

How to test: In DevTools, combine the Network panel with the Performance panel. Look for blocking scripts in the waterfall and long tasks during parse, style, layout, and paint. PageSpeed Insights can flag render-blocking resources and main-thread work, but confirm the finding in the trace rather than treating the score as the diagnosis.

Common fixes include deferring noncritical JavaScript, splitting bundles, removing unused CSS, preloading the right font files, setting image dimensions, and moving expensive work out of the critical path.

Verdict: Not the host. A stronger CPU on the origin server will not reduce the JavaScript execution cost on a visitor’s phone.

Network path, routing, and peering

Symptom: The site is fast for you and slow for a specific country, ISP, office, or mobile carrier. TTFB may be acceptable near the data center and poor near the audience. Packet loss or route detours appear in MTR.

How to test: Run path tests from the visitor geography, not only from your workstation:

mtr -rwzc 100 example.com
traceroute example.com
ping -c 50 example.com

Ask users in the affected region to run the same tests, or use a Looking Glass near them. Compare routes by ASN and city, not just hop count. A physically close server can still take a poor carrier path. A farther server with better peering can sometimes behave better for the audience you care about. For planning, match the node location to the visitor geography you actually need to serve.

Verdict: Host-related. Node location, carrier mix, transit quality, peering, and return path all belong to the hosting network decision. Your application code cannot fix a bad route to your main audience.

So is it actually the host?

Hosting is the proven bottleneck when the evidence points below the application layer.

Strong host signals include high TTFB on a tiny static file from multiple test networks, sustained CPU steal or disk wait on a lightly loaded VPS, RAM pressure that you did not create, packet loss on the path to the origin, or poor routing to your main visitor geography. Another common signal is the regional split: “fine for me, slow for visitors elsewhere.” That often means the node is in the wrong region or the network path is poor for that audience.

Weak host signals include a low PageSpeed score with huge images, slow dynamic pages while static files are fast, long JavaScript tasks after HTML arrives, or missing cache headers. Those problems can follow you to any provider.

Decision flowchart

Slow before connection starts
  -> likely layer: DNS
  -> fix: authoritative DNS, registrar records, resolver path, TTL policy

High TCP or TLS time
  -> likely layer: distance, routing, protocol support, TLS config
  -> fix: closer node, better route, HTTP/2 or HTTP/3, clean certificate setup

High TTFB on static and dynamic URLs
  -> likely layer: host, origin web server, CDN miss path, routing
  -> fix: inspect VPS load, CPU steal, disk wait, packet loss, node location

High TTFB only on dynamic URLs
  -> likely layer: application or database
  -> fix: page cache, query profiling, PHP/runtime tuning, upstream timeout review

Low TTFB but high total load time
  -> likely layer: payload
  -> fix: compress text, resize images, reduce JS and CSS, cache assets

HTML arrives quickly but the page is still unusable
  -> likely layer: front-end rendering
  -> fix: remove render blockers, reduce main-thread work, defer noncritical scripts

Slow only for one geography or carrier
  -> likely layer: routing and peering
  -> fix: choose a better node, test Looking Glass paths, use CDN or provider with better regional routing

When changing or upgrading hosting genuinely helps

Changing providers helps when the host is the measured bottleneck: an oversold VPS with CPU steal, an instance without enough RAM or disk performance, a node far from your users, weak peering to the target region, no IPv6 where your audience benefits from it, no HTTP/3 or modern edge support in your delivery path, or an IP setup that does not fit the service.

If your measurements point to location or routing as the bottleneck, compare Riven Cloud’s Tokyo and Singapore locations and network paths. When those match your audience, you can view VPS plans or order from the Riven Cloud portal.

Conclusion

The next time the question is “why is my website slow?”, do not start with a provider migration. Start with the waterfall, split static from dynamic, check the path, and name the slow layer.

Switching hosts helps when hosting is the proven bottleneck. If DNS is broken, fix DNS. If the app is generating pages slowly, fix the app or cache it. If the payload is too large, shrink it. If the route to your users is bad, then hosting location and network quality become the right problem to solve.

Many buyers already know what to look for on China Telecom: CN2 GIA, CTGNet, AS4809, AS23764. They may also know China Unicom Premium through AS9929 and AS10099. China Mobile has its own premium path, and the signal to look for is CMIN2 / AS58807.

For China Mobile users, the route question is simple:

Does traffic move from China Mobile AS9808 into CMIN2 / AS58807,
or does it fall back to ordinary CMI / AS58453 and standard international transit?

For Riven Cloud Tokyo, the optimized China Mobile path in the June 29, 2026 sample was:

China Mobile access / regional network
-> China Mobile domestic backbone / AS9808
-> CMIN2 / China Mobile International N2 / AS58807
-> Riven Cloud Tokyo / AS3258

The ordinary SoftBank transit baseline from the same comparison set looked different:

China Mobile access / regional network
-> China Mobile AS9808
-> ordinary CMI / AS58453
-> SoftBank AS17676
-> AS3258 Tokyo endpoint

That difference matters. A VPS can be in Japan and still take the wrong carrier path for China Mobile users.

The China Mobile networks customers should know

China Mobile routing has several layers. For VPS buyers, four ASNs are worth knowing.

Hurricane Electric’s BGP Toolkit lists AS9808 as China Mobile Communications Group Co., Ltd.. That is the domestic China Mobile backbone side. A user may start from a provincial or regional China Mobile network first, then enter AS9808.

PeeringDB lists AS58807 as China Mobile International - NII, with CMIN2 as its also-known-as value. The same PeeringDB record shows AS58807 at Tokyo, Singapore, Hong Kong, Frankfurt, and other interconnection points. BGP.tools also lists AS58807 as China Mobile International Limited, with prefix descriptions such as Japan N2 Network, Singapore N2 Network, and Germany N2 Network.

Hurricane Electric’s BGP Toolkit lists AS58453 as China Mobile International Limited. In the baseline route below, AS58453 appears as the ordinary CMI international side before SoftBank AS17676. PeeringDB lists AS17676 as SoftBank Corp., and AS3258 as xTom Tokyo.

Use this practical map:

• China Mobile regional or access networks: where many broadband, enterprise, or mobile users begin.
• AS9808: China Mobile’s domestic backbone.
• AS58807: CMIN2 / China Mobile International N2, the premium international path.
• AS58453: ordinary China Mobile International / CMI, commonly seen on standard China Mobile international routes.
• AS17676: SoftBank, used in the standard transit baseline.
• AS3258: the Tokyo network used by the test endpoints.

AS9808 is the domestic side. AS58807 is the premium CMIN2 international side. A strong China Mobile optimized route should show traffic moving from AS9808 into AS58807 before it reaches the VPS provider.

What CMIN2 means

CMIN2 means China Mobile International N2. In the VPS market, it is the premium China Mobile path customers should look for when evaluating China Mobile optimized connectivity.

It plays a similar customer-facing role for China Mobile users as CN2 GIA does for China Telecom users or CUP / AS9929 does for China Unicom users. It is not the same network and should not be described as the same product. The useful comparison is functional: it gives China Mobile traffic a carrier-matched premium path instead of pushing it through ordinary international transit.

For Riven Cloud, the shorthand is:

China Mobile traffic from mainland China
-> AS9808 domestically
-> CMIN2 / AS58807 internationally
-> Riven Cloud Tokyo / AS3258

The old habit of checking only Telecom and Unicom is incomplete. If your users are on China Mobile broadband or China Mobile 5G, AS58807 is the route signal to check.

CMIN2 / AS58807 and ordinary CMI / AS58453 are not the same route

CMIN2 and ordinary CMI are related to China Mobile International, but they should not be treated as interchangeable.

AS58807 is the CMIN2 / N2 premium path. It is the AS Riven Cloud peers with for China Mobile optimized routing, and it is the desired path for China Mobile users accessing the Riven Cloud Tokyo optimized node.

AS58453 is the ordinary CMI path seen in the baseline route. It can be useful for general Internet traffic, but in this China Mobile to Tokyo sample it then handed traffic to SoftBank AS17676 before reaching AS3258.

That is the operational split:

Optimized:
AS9808 -> CMIN2 / AS58807 -> AS3258

Standard transit baseline:
AS9808 -> ordinary CMI / AS58453 -> SoftBank AS17676 -> AS3258

The names sound close enough to confuse people. The routes are visibly different.

The Riven Cloud China Mobile CMIN2 path

The optimized path for China Mobile users is:

China Mobile user
-> China Mobile regional/access network
-> China Mobile domestic backbone / AS9808
-> CMIN2 / China Mobile International N2 / AS58807
-> Riven Cloud Tokyo / AS3258

Each part has a job:

• The user may start from a regional China Mobile access network, such as a provincial CMNET segment.
• AS9808 is the China Mobile domestic backbone.
• AS58807 is CMIN2 / China Mobile International N2.
• AS3258 is the Tokyo network used by the Riven Cloud optimized test node.

Riven Cloud peers with China Mobile through CMIN2 / AS58807. China Mobile traffic from mainland China uses AS9808 domestically before reaching CMIN2 / AS58807, then Riven Cloud.

Optimized route MTR sample

The optimized mainland China to Tokyo sample came from a third-party MTR-style capture with 20 probes. The return MTR from Tokyo to mainland China started at 2026-06-29T10:34:03+0000 and used 10 probes.

The forward sample showed a China Mobile regional access side, AS9808, CMIN2 / AS58807, and the final Riven Cloud endpoint on AS3258. The return sample showed AS3258, then AS58807, then AS9808, then the China Mobile access endpoint.

The optimized route shows the expected China Mobile premium structure in both directions. Traffic moves between AS9808 and CMIN2 / AS58807, instead of using ordinary CMI and standard transit.

Standard SoftBank transit comparison

The same June 29, 2026 comparison set included a standard SoftBank transit baseline to an AS3258 Tokyo endpoint. It was not the same destination IP as the Riven Cloud optimized node, so treat it as a route-pattern baseline rather than a same-host A/B test.

The baseline path was:

China Mobile user
-> China Mobile regional/access network
-> China Mobile AS9808
-> ordinary CMI / AS58453
-> SoftBank AS17676
-> AS3258 Tokyo endpoint

Cleaned final-hop results from that baseline were:

This does not mean SoftBank or ordinary CMI is bad. They can be fine for many general routes. For this China Mobile to Tokyo sample, the standard transit path had much higher average RTT than the CMIN2 optimized path.

Side-by-side results

The CMIN2 optimized path reduced average RTT in both directions.

The latency reduction is useful. The path evidence is the bigger point: the optimized route used AS58807, the intended China Mobile premium path, instead of ordinary CMI / AS58453 and standard international transit.

For China Mobile customers, this is the missing piece in many route comparisons. Telecom may have CN2/CTGNet. Unicom may have AS9929/AS10099. Mobile needs its own premium path too.

Why CMIN2 matters for China Mobile users

China Mobile users were often the weak spot in older “China optimized” VPS offers. A provider might optimize for China Telecom and China Unicom, then leave China Mobile to ordinary international routing.

CMIN2 changes the checklist. China Mobile users can now look for a premium path of their own: AS9808 on the domestic side, AS58807 on the international side, then the provider network.

In practical terms, that can mean:

• Lower latency for China Mobile users.
• More responsive SSH sessions.
• Faster website loading from China Mobile networks.
• Better API response times from mainland China.
• Smoother control panel or remote desktop access.
• Less dependence on ordinary transit paths.
• Better carrier matching for services with China Mobile users.

The route does not make every application fast. It removes one common source of delay: sending China Mobile traffic through a less suitable international path.

How to check whether a route is really CMIN2

A CMIN2 route should usually show:

• AS9808 on the mainland China domestic side.
• AS58807 on the China Mobile International N2 side.
• The provider AS after AS58807.

For Riven Cloud Tokyo, the expected optimized pattern is:

China to Tokyo:
China Mobile access -> AS9808 -> AS58807 -> AS3258

Tokyo to China:
AS3258 -> AS58807 -> AS9808 -> China Mobile access

The ordinary baseline pattern may look like this:

China Mobile access -> AS9808 -> AS58453 -> AS17676 -> AS3258

Router IPs and city codes can change. The AS-level pattern is the part to check first.

How to read MTR without chasing noise

MTR is useful, but it is not a packet-loss oracle.

Intermediate routers may rate-limit ICMP, ignore probes, or show strange control-plane latency while still forwarding customer traffic normally. A 100% non-response on an intermediate hop does not prove end-to-end packet loss when later hops and the final destination continue to respond.

The optimized return sample is a good example. Several early AS3258 intermediate hops reported high latency or loss-like behavior, but later AS58807, AS9808, and final access-network hops were normal. The final destination showed 44.7 ms average RTT, 44.6 ms best RTT, and 0.0% packet loss.

When checking CMIN2 routes, focus on:

• Final-hop average RTT.
• Final-hop packet loss.
• Whether the path shows AS9808 and AS58807.
• Whether the return direction also uses AS58807 and AS9808.
• Whether intermediate loss continues to the final destination.

Short MTR samples are useful route evidence. They are not an SLA for every province, every hour, or every future routing change.

What CMIN2 cannot guarantee

CMIN2 gives China Mobile traffic a better path. It does not make every last-mile network perfect.

Performance can still depend on province, local China Mobile access quality, home broadband or 5G conditions, time of day, carrier routing changes, international cable incidents, firewall behavior, application protocol, customer-side Wi-Fi, and router quality.

CMIN2 also cannot make all mobile networks behave like fiber broadband. A phone on a congested cell, a home router with poor Wi-Fi, or an application with bad retry behavior can still feel slow.

Treat the route as one part of the deployment decision, alongside CPU, RAM, NVMe storage, monthly transfer, backup policy, and application design.

Conclusion

For China Mobile users, Riven Cloud’s optimized Tokyo route is designed around the CMIN2 premium path:

China Mobile access / regional network
-> AS9808 domestic backbone
-> CMIN2 / China Mobile International N2 / AS58807
-> Riven Cloud Tokyo / AS3258

In the June 29, 2026 samples, that path delivered 40.0 ms average RTT from mainland China to Tokyo and 44.7 ms average RTT from Tokyo back to mainland China, both with 0.0% final-hop packet loss.

The standard SoftBank transit baseline averaged 72.2 ms from mainland China to Tokyo and 70.0 ms in the return direction. The cleaner result came from the path choice: AS9808 into CMIN2 / AS58807 instead of AS58453 and SoftBank transit.

For the full three-network view, read What are China-optimized routes? CTGNet/CN2 GIA, CUP, and CMIN2 explained. For the other carrier-specific articles, see China Telecom premium routing and China Unicom Premium routing.

If your users are on China Mobile in mainland China, test the path from the Tokyo Looking Glass and compare it with your current route. If the CMIN2 path fits your users, view the Riven Cloud VPS plans and deploy a Tokyo server built for China Mobile traffic to take the right carrier path before it reaches your application.

For China Telecom users, the useful question is whether traffic uses the premium China Telecom route in both directions: the China Telecom access network, the CN2/AS4809 premium segment, the current CTGNet/AS23764 international delivery path, and then the VPS provider network.

For Riven Cloud Tokyo, the optimized China Telecom path is:

China Telecom access network / AS4134
-> CN2 premium segment / AS4809 / 59.43
-> CTGNet international edge / AS23764
-> Riven Cloud Tokyo / AS3258

That is materially different from a normal international transit path such as:

China Telecom AS4134
-> SoftBank AS17676
-> Riven Cloud Tokyo / AS3258

The MTR samples in this article were collected on June 29, 2026. They are short samples, not an SLA. They are useful because they show both the visible AS path and the final-hop behavior for the optimized China Telecom route, then compare it with a standard SoftBank transit baseline from the same test set.

China Telecom routing has several moving parts

China Telecom routing is easy to oversimplify because several related names show up in the same conversation.

China Telecom’s Global Internet Access page says the service offers access to ChinaNet (AS4134) and CN2 (AS4809). Public PeeringDB records list CTGNet as AS23764 with the IRR as-set AS-CTGNET, and China Telecom / CN2 as AS4809 with the IRR as-set AS-CN2.

For VPS buyers, the practical map looks like this:

• AS4134: ChinaNet / China Telecom’s large public Internet backbone and access network.
• AS4809: CN2 / China Telecom’s premium backbone segment, commonly associated with CN2 GIA in the VPS market.
• AS23764: CTGNet / China Telecom Global’s international network used for peering and international delivery.

A China Telecom broadband user may begin in AS4134 or a regional access network. A premium route should move the traffic into the CN2/AS4809 segment and then use CTGNet/AS23764 for the international handoff.

That last point is where many route descriptions get sloppy. CTGNet and CN2 GIA are related in how customers experience the route, but they are not interchangeable terms.

What CN2 GIA means in practice

CN2 GIA is market shorthand for China Telecom’s premium global Internet access route. VPS buyers usually associate it with the CN2/AS4809 backbone, lower latency, less congestion, and more predictable cross-border performance than ordinary ChinaNet routes.

The label alone does not prove much. A useful route check asks two questions:

• Does the route show the premium CN2 segment, often visible as 59.43 hops or AS4809?
• Does the international handoff avoid ordinary transit and land on the intended China Telecom Global path?

In practice, customers should look less at the label and more at the path. A trace that says “CN2” somewhere in the middle is weaker evidence than a clean path showing China Telecom access, CN2/AS4809, CTGNet/AS23764, and the provider network in both directions.

What CTGNet means in this route

CTGNet is the China Telecom Global international network associated with AS23764. In the Riven Cloud Tokyo route, CTGNet is the peer-facing international side of the China Telecom path.

CN2/AS4809 is the premium China Telecom segment that mainland China users have historically associated with CN2 GIA. CTGNet/AS23764 is the international delivery and interconnection side used in the current route.

Riven Cloud peers with China Telecom through CTGNet / AS23764. China Telecom traffic from mainland China uses the CN2 / AS4809 premium segment before reaching CTGNet / AS23764, where it is handed to Riven Cloud’s Tokyo network on AS3258. PeeringDB lists AS3258 as xTom Tokyo, which matches the Tokyo network context for this service.

The clean shorthand is:

AS4134 access
-> CN2 / AS4809 / 59.43
-> CTGNet / AS23764
-> Riven Cloud Tokyo / AS3258

The Riven Cloud China Telecom path

The optimized path from a China Telecom user to Riven Cloud Tokyo should show the China Telecom access side first, then the premium CN2 segment, then CTGNet, then the Riven Cloud endpoint.

China Telecom user
-> China Telecom access network / AS4134
-> CN2 premium segment / AS4809 / 59.43
-> CTGNet international edge / AS23764
-> Riven Cloud Tokyo / AS3258

Each part has a job:

• AS4134 is where many ordinary China Telecom users begin.
• The 59.43 hops indicate the CN2 premium segment.
• CTGNet / AS23764 is the international handoff and China Telecom peer path.
• AS3258 is the Tokyo network used by the Riven Cloud test node.

The reverse direction matters as much as the forward direction. A route can look good from China to Tokyo and still return through a different, less suitable path. The Riven Cloud sample below showed the expected CTGNet and CN2 path in both directions.

Optimized route MTR sample

The optimized MTR samples were collected on June 29, 2026 at 2026-06-29T10:22:04+0000 for mainland China to Tokyo and 2026-06-29T10:23:28+0000 for Tokyo to mainland China. Each sample used 10 probes.

The raw output showed China Telecom AS4134 near the access side, multiple 59.43 hops on the CN2 segment, CTGNet hostnames such as ct163.jp.tyo.ctgnet and jp.tyo.ctgnet, and the final Riven Cloud Tokyo endpoint on AS3258.

The optimized route shows the expected premium China Telecom path in both directions. Traffic does not simply exit China Telecom through ordinary international transit. It uses the CN2/59.43 segment and CTGNet/AS23764 before reaching the Riven Cloud Tokyo network.

Standard SoftBank transit comparison

SoftBank is a normal international transit path. PeeringDB lists SoftBank Corp. as AS17676. There is nothing inherently wrong with using SoftBank for general Internet traffic.

For this China Telecom to Tokyo comparison, the baseline path was less suitable:

China Telecom user
-> China Telecom AS4134
-> SoftBank AS17676
-> Riven Cloud Tokyo / AS3258

The standard transit baseline from the same June 29, 2026 test set showed higher final-hop RTT than the CTGNet/CN2 optimized path.

This sample does not prove that SoftBank is bad. It shows the difference between a generic international transit path and a China Telecom matched premium path for this specific Tokyo VPS use case.

Side-by-side results

The RTT gap was large in both directions.

In this sample, the CTGNet/CN2 optimized route reduced average RTT by more than 40 ms in the China-to-Tokyo direction and more than 30 ms in the return direction. The path itself is the more important signal: the optimized route used the intended China Telecom premium network instead of ordinary international transit.

That route choice is what customers should evaluate when they compare CN2 GIA VPS offers. A low number in one ping test is useful. A clean premium carrier path in both directions is better evidence.

What customers feel

Most customers do not buy AS paths for their own sake. They care whether a server feels usable from mainland China.

For China Telecom users, a better matched route can show up in practical ways:

• SSH sessions feel more responsive.
• Control panels and dashboards spend less time waiting on the network.
• API calls from mainland China have lower round-trip delay.
• Websites load faster for China Telecom users.
• Real-time applications have less room for jitter to become visible.
• Evening peak is less likely to be dominated by ordinary international transit congestion.

The word “likely” matters. Route optimization improves the path. It does not make every application fast, and it does not remove every local access problem.

How to read MTR without fooling yourself

MTR is useful, but it is easy to overread.

Focus on the final destination, the overall RTT pattern, and the visible AS path. Intermediate packet loss can be caused by ICMP rate limiting, router control-plane protection, or devices that simply do not answer probes. A 100% non-response on an intermediate hop does not prove end-to-end loss when later hops and the final destination still respond normally.

For this comparison, the important checks are:

• Final-hop average RTT.
• Final-hop packet loss.
• Whether the visible path uses CN2/59.43/AS4809.
• Whether the international handoff uses CTGNet/AS23764.
• Whether the return path also uses the premium China Telecom route.

Short MTR samples are useful route evidence. They are not a guarantee for every province, every hour, or every future carrier policy change.

What CTGNet/CN2 cannot guarantee

Premium China Telecom routing gives traffic a better path. It does not suspend the laws of the Internet.

Performance can still depend on the user’s province, local access network, time of day, submarine cable events, carrier routing changes, firewall behavior, application protocol, customer-side Wi-Fi, and last-mile conditions.

A clean CTGNet/CN2 path reduces dependence on ordinary international transit. It cannot control every hop before the user reaches China Telecom’s backbone, and it cannot guarantee that every application will use the network efficiently.

Treat route optimization as one important part of a deployment decision, alongside CPU, RAM, NVMe storage, transfer quota, backup policy, and application design.

Conclusion

For China Telecom users, Riven Cloud’s optimized Tokyo route is built around the premium China Telecom path:

AS4134 access network
-> CN2 / AS4809 premium segment
-> CTGNet / AS23764 international delivery
-> Riven Cloud Tokyo / AS3258

The June 29, 2026 sample showed much lower average RTT than ordinary SoftBank transit in both directions: 36.3 ms versus 78.1 ms from mainland China to Tokyo, and 41.6 ms versus 74.1 ms from Tokyo back to mainland China.

CTGNet and CN2 should be read as parts of the current China Telecom premium routing path, not as interchangeable words. The useful question is whether the actual path shows the premium China Telecom network in both directions.

For a broader carrier view, read What are China-optimized routes? CTGNet/CN2 GIA, CUP, and CMIN2 explained. For the other carrier-specific articles, see China Unicom Premium routing and China Mobile CMIN2 routing. To test from Riven Cloud’s Tokyo location, use the Tokyo Looking Glass.

China Unicom Premium, often called CUP in the VPS market, is better understood as a two-part premium path:

China Unicom access / AS4837
-> China Unicom Premium / AS9929
-> China Unicom Global / AS10099
-> Riven Cloud Tokyo / AS3258

The value of the route is in that structure. A good China Unicom Premium path should move traffic from the normal AS4837 access or regional side into AS9929, then use China Unicom Global AS10099 for international delivery before reaching Riven Cloud.

For Riven Cloud Tokyo, the optimized Unicom path in the June 29, 2026 MTR samples was:

Mainland China to Tokyo:
AS4837 -> AS9929 -> AS10099 -> AS3258

Tokyo to mainland China:
AS3258 -> AS10099 -> AS9929 -> AS4837

Those two directions matter. A route that shows AS9929 in one direction and ordinary transit in the other direction is not the same operational result.

The China Unicom networks customers should know

China Unicom routing usually involves three ASNs in this discussion.

China Unicom Global’s DIA page describes AS4837 as China Unicom’s backbone Internet network and says its mainland China DIA service can use the premium bearer network AS9929. The same page describes AS9929 as light loaded and better performing for premium DIA. Its IPT & peering page describes AS10099 as China Unicom’s international network for flexible usage patterns and customized routes.

Public PeeringDB records also match the ASN identities: AS10099 is China Unicom Global, AS9929 is China Unicom Industrial Internet Backbone, and AS3258 is xTom Tokyo.

For route analysis, use this practical map:

• AS4837: China Unicom’s common public Internet backbone and access or regional network.
• AS9929: the premium Unicom bearer segment, usually the part VPS buyers look for when checking a CUP route.
• AS10099: China Unicom Global’s international network and the peer-facing side for Riven Cloud.
• AS3258: the Tokyo network used by the Riven Cloud test node.

AS4837 at the beginning of a trace is not a red flag by itself. Many Unicom users begin there. The route becomes interesting when traffic moves from AS4837 into AS9929, then reaches AS10099 before the provider network.

What China Unicom Premium means in practice

China Unicom Premium is the market name commonly used for the premium Unicom cross-border route. In practice, a strong CUP route usually means AS9929 on the mainland China side and China Unicom Global AS10099 on the international side.

The name alone does not prove much. The path should show how the access network, premium Unicom segment, international network, and provider network connect.

China Unicom user
-> China Unicom access / AS4837
-> China Unicom Premium / AS9929
-> China Unicom Global / AS10099
-> Riven Cloud Tokyo / AS3258

Riven Cloud peers with China Unicom Global through AS10099. China Unicom traffic from mainland China enters the premium AS9929 segment before reaching AS10099 and Riven Cloud.

AS9929 and AS10099 are different parts of the route

AS9929 and AS10099 are not interchangeable.

AS9929 is the premium Unicom segment customers usually see on the mainland China side. It often appears after AS4837 access or regional hops. In the sample route below, traffic starts on AS4837, then enters AS9929 at hop 8 in the mainland China to Tokyo direction.

AS10099 is China Unicom Global’s international network. It is the AS Riven Cloud peers with for China Unicom Premium, and it handles the international side before traffic reaches Riven Cloud’s Tokyo network.

A useful CUP check looks for both parts. Seeing only one ASN is weaker evidence than seeing the full AS4837 -> AS9929 -> AS10099 -> AS3258 pattern, with the reverse direction matching the same structure.

The Riven Cloud China Unicom Premium path

The optimized China Unicom path for Riven Cloud Tokyo is:

China Unicom user
-> China Unicom AS4837 access / regional network
-> China Unicom Premium AS9929
-> China Unicom Global AS10099
-> Riven Cloud Tokyo AS3258

Each part has a role:

• AS4837 may appear because many users start from ordinary China Unicom access or regional networks.
• AS9929 is the premium Unicom segment.
• AS10099 is the China Unicom Global international side.
• AS3258 is the Riven Cloud Tokyo test network.

AS4837 near the access side does not mean the route failed to use premium Unicom routing. The next step is the useful part: whether the path moves into AS9929 and then AS10099.

Optimized route MTR sample

The optimized MTR samples below were collected on June 29, 2026. The mainland China to Tokyo sample started at 2026-06-29T10:20:30+0000. The Tokyo to mainland China sample started at 2026-06-29T10:20:36+0000. Each MTR used 10 probes.

The visible AS path matched the expected China Unicom Premium structure in both directions.

The mainland China to Tokyo MTR showed AS4837 on the access side, then AS9929, then AS10099, and the final Riven Cloud Tokyo endpoint on AS3258. The return MTR showed AS3258 first, then AS10099, then AS9929, and the final China Unicom endpoint on AS4837.

That is the important production signal: the route uses AS9929 and AS10099 in both directions, instead of leaving China Unicom through a generic international transit path.

Standard SoftBank transit comparison

The same June 29, 2026 comparison set also included a standard SoftBank transit baseline. SoftBank AS17676 is a normal international transit network. The point of the comparison is route matching for China Unicom users, not a claim that SoftBank is a bad network.

The baseline path was:

China Unicom user
-> China Unicom AS4837
-> SoftBank AS17676
-> Riven Cloud Tokyo AS3258

Cleaned final-hop results from that baseline were:

For this Unicom to Tokyo sample, the standard transit path had higher average RTT than the China Unicom Premium route in both directions.

Side-by-side results

The optimized path reduced average RTT in both directions.

The RTT reduction is useful, but the cleaner route structure is the bigger signal. The optimized route used the intended China Unicom premium path rather than ordinary international transit.

For customers comparing AS9929 VPS or CUP VPS offers, this is the check that matters: AS4837 access, AS9929 premium segment, China Unicom Global AS10099, and the provider AS in both directions.

Why this matters for VPS users

Most customers do not care about AS paths until the network starts wasting their time.

For China Unicom users, a carrier-matched path can improve ordinary daily work:

• SSH sessions feel more responsive.
• Websites load faster for users on China Unicom.
• API calls from mainland China spend less time waiting on the network.
• Control panels and remote desktop sessions feel less sticky.
• Latency-sensitive applications get a cleaner path to Tokyo.
• The service depends less on ordinary international transit during busy hours.

The result still depends on the user’s local line and application behavior. Route optimization gives the traffic a better path. It does not make every last-mile network perfect.

How to check whether a route is really China Unicom Premium

A good Unicom premium route often shows this pattern:

• AS4837 near the access side.
• AS9929 as the premium Unicom segment.
• AS10099 as the China Unicom Global international network.
• The provider AS after AS10099.

For Riven Cloud Tokyo, the expected optimized pattern is:

China to Tokyo:
AS4837 -> AS9929 -> AS10099 -> AS3258

Tokyo to China:
AS3258 -> AS10099 -> AS9929 -> AS4837

Exact router IPs, hostnames, and city codes may change. The AS-level pattern is the part to check first.

How to read MTR without chasing the wrong problem

MTR is useful, but intermediate hops can mislead.

Routers may rate-limit ICMP, deprioritize control-plane replies, or ignore probes while still forwarding customer traffic normally. A 100% non-response on an intermediate hop does not prove end-to-end packet loss when later hops and the final destination continue to respond.

The Tokyo to mainland China sample shows why this matters. Hop 5 reported 50.0% loss and a very high average latency, but later hops returned to normal and the final destination showed 36.6 ms average RTT with 0.0% packet loss. Treat that kind of isolated intermediate behavior as a diagnostic clue, not as final proof of customer traffic loss.

When checking CUP routes, focus on:

• Final-hop average RTT.
• Final-hop packet loss.
• Whether the path shows AS9929 and AS10099.
• Whether the return direction also uses AS10099 and AS9929.
• Whether the same loss pattern continues to the final destination.

Short MTR samples are useful route evidence. They are not an SLA for every province, every hour, or every future routing change.

What China Unicom Premium cannot guarantee

China Unicom Premium gives traffic a better path. It does not make every last-mile network perfect.

Performance can still depend on province, local broadband quality, office or residential network conditions, last-mile congestion, time of day, carrier routing changes, international cable incidents, application protocol, customer-side Wi-Fi, and customer router behavior.

CUP reduces dependence on ordinary international transit for China Unicom users. It cannot control every access network before AS4837, and it cannot fix an application that handles latency poorly.

Treat the route as one part of the deployment decision, alongside CPU, RAM, NVMe storage, monthly transfer, backup policy, and application design.

Conclusion

For China Unicom users, Riven Cloud’s optimized Tokyo route is designed around the real China Unicom Premium path:

AS4837 access / regional network
-> AS9929 premium segment
-> China Unicom Global AS10099
-> Riven Cloud Tokyo AS3258

In the June 29, 2026 MTR samples, that path delivered 37.4 ms average RTT from mainland China to Tokyo and 36.6 ms average RTT from Tokyo back to mainland China, both with 0.0% final-hop packet loss.

The same-day standard SoftBank transit baseline averaged 53.1 ms from mainland China to Tokyo and 57.0 ms in the return direction. The lower RTT helps, but the route evidence is the real point: the optimized route shows the expected AS9929 and AS10099 path in both directions.

For a broader carrier view, read What are China-optimized routes? CTGNet/CN2 GIA, CUP, and CMIN2 explained. For the other carrier-specific articles, see China Telecom premium routing and China Mobile CMIN2 routing. To test from Riven Cloud’s Tokyo location, use the Tokyo Looking Glass.

A China Telecom home connection, a China Unicom office line, and a China Mobile phone can take different international paths to the same VPS. A route that looks fine for one carrier may be the wrong path for another.

In the mainland China VPS market, “three-network optimization” means treating the three major carrier networks separately:

• China Telecom
• China Unicom
• China Mobile

Riven Cloud’s optimized Tokyo routing is built around that model. China Telecom traffic uses the CN2/AS4809 domestic premium path and reaches Riven Cloud through CTGNet/AS23764. China Unicom traffic uses AS9929 on the mainland China side and reaches Riven Cloud through China Unicom Global AS10099. China Mobile traffic uses AS9808 domestically and reaches Riven Cloud through CMIN2/AS58807.

Lower latency is part of the story, but carrier matching matters just as much. A good China route should avoid pushing all three carriers through the same ordinary transit path and hoping the result holds during peak hours.

The comparison data below comes from cleaned MTR samples collected on June 29, 2026. Exact customer endpoints, VPS addresses, router IPs, private IPs, and hostnames have been redacted. The article keeps the parts that matter for route analysis: carrier labels, ASNs, direction, final-hop average RTT, final-hop packet loss, and visible AS-level paths.

What are the three networks in China?

China Telecom, China Unicom, and China Mobile are the three carrier networks most VPS buyers care about when serving users in mainland China.

That matters because a “China route” is not a single path. A user in Shanghai on China Telecom, a developer in Beijing on China Unicom, and a phone on China Mobile can take very different routes to the same VPS in Tokyo. A path that works well for one carrier may be ordinary, indirect, or congested for another.

A China-optimized route needs to be carrier-specific. One decent international transit provider is not the same thing as three-network optimization.

Why ordinary international transit is not enough

Standard global transit can be good for general international traffic. For users in North America, Europe, Japan, Singapore, and many other markets, a well-connected transit blend may be perfectly reasonable.

Mainland China traffic is different. The route depends heavily on carrier-specific international gateways, domestic backbone policy, handoff points, and the relationship between the overseas network and each Chinese carrier.

Ordinary transit may enter China through a less ideal carrier path. It may take a detour through another region. It may work acceptably at one time of day and become inconsistent during evening peak. It may also be asymmetric: the route from China to Tokyo can look different from the route from Tokyo back to China.

Bandwidth is only one part of network quality. For many applications, latency, packet loss, jitter, and route consistency matter more than a large port number on a plan page. A 1 Gbps port does not help much if packets reach the wrong international gateway or bounce through a congested carrier path.

China Telecom: CTGNet and CN2 GIA

China Telecom is the easiest one to mislabel.

CTGNet is China Telecom’s newer premium international network, associated with AS23764. CN2, commonly discussed in the VPS market as CN2 GIA, is tied to the premium China Telecom backbone segment associated with AS4809. These are related in the customer experience, but they are not the same phrase with two names.

Riven Cloud’s path should not be described as “CTGNet equals CN2 GIA.” The domestic premium segment and the international delivery path are different parts of the route. In this setup, China Telecom traffic uses the CN2/AS4809 domestic premium segment and reaches Riven Cloud through CTGNet/AS23764.

Riven Cloud peers with China Telecom through CTGNet AS23764. On the mainland China side, traffic can traverse the CN2/59.43 segment associated with AS4809 before it reaches the CTGNet AS23764 edge and then Riven Cloud’s Tokyo network.

As of June 29, 2026, PeeringDB lists CTGNet as AS23764. That public record matches the peer-facing ASN discussed here.

In our sample MTR tests, the optimized China Telecom route showed an average final-hop RTT of 36.3 ms from a China Telecom access sample to the Riven Cloud Tokyo optimized test node, with 36.1 ms best RTT and 0.0% final-hop packet loss. In the reverse direction, from Tokyo back to the China Telecom access sample, the optimized route showed 41.6 ms average final-hop RTT, 41.6 ms best RTT, and 0.0% final-hop packet loss.

The ordinary SoftBank transit baseline for the same carrier sample used AS4134 -> SoftBank AS17676 -> Riven Cloud AS3258 in the China-to-Tokyo direction, and Riven Cloud AS3258 -> SoftBank AS17676 -> AS4134 in the return direction. The final hop averaged 78.1 ms with 30.0% packet loss from China to Tokyo, and 74.1 ms with 10.0% packet loss from Tokyo back to China.

This does not mean every China Telecom user will always see those exact numbers. It does show the route difference clearly: CN2/AS4809 and CTGNet/AS23764 on the optimized path, compared with ordinary SoftBank transit on the baseline path.

For the carrier-specific breakdown, read What is CTGNet / CN2 GIA? China Telecom premium routing explained.

China Unicom: CUP and China Unicom Premium

CUP means China Unicom Premium.

For Riven Cloud’s optimized China Unicom path, the mainland China side uses AS9929 as the premium backbone and international exit segment. Riven Cloud peers with China Unicom Global through AS10099. AS4837 may still appear before traffic enters AS9929, because AS4837 is commonly seen as an ordinary China Unicom regional or access network.

The accurate shorthand is:

China Unicom traffic uses AS9929 on the mainland China side and reaches Riven Cloud through China Unicom Global AS10099.

As of June 29, 2026, PeeringDB lists China Unicom Global as AS10099. In the optimized sample, the visible AS path from mainland China to Tokyo was AS4837 -> AS9929 -> AS10099 -> Riven Cloud AS3258. The return direction showed Riven Cloud AS3258 -> AS10099 -> AS9929 -> AS4837.

The useful part is where AS9929 appears. AS4837 may still show up near the access side, but the cross-border segment moves onto the premium Unicom path through AS9929 and AS10099.

In our sample, the optimized China Unicom route averaged 37.4 ms from China to Tokyo, with 37.1 ms best RTT and 0.0% final-hop packet loss. The return direction averaged 36.6 ms, with 36.6 ms best RTT and 0.0% final-hop packet loss.

The ordinary SoftBank transit baseline used AS4837 -> SoftBank AS17676 -> Riven Cloud AS3258 from China to Tokyo, and Riven Cloud AS3258 -> SoftBank AS17676 -> AS4837 in the return direction. It averaged 53.1 ms from China to Tokyo and 57.0 ms from Tokyo back to China, both with 0.0% final-hop packet loss.

For the carrier-specific breakdown, read What is China Unicom Premium? CUP, AS9929, and AS10099 explained.

China Mobile: CMIN2

CMIN2 means China Mobile International N2. It is the important path to look for when evaluating optimized China Mobile routing.

Riven Cloud peers with CMIN2 through AS58807. Mainland China traffic uses AS9808 domestically before reaching AS58807. In contrast, ordinary China Mobile international routes may use older CMI paths such as AS58453, often with additional transit such as SoftBank AS17676 in the baseline route.

The accurate shorthand is:

China Mobile traffic uses AS9808 domestically and reaches Riven Cloud through CMIN2/AS58807.

As of June 29, 2026, PeeringDB lists China Mobile International - NII as AS58807, with CMIN2 as its listed aka.

In our optimized sample, the visible AS path from mainland China to Tokyo was China Mobile regional/access network -> AS9808 -> CMIN2 AS58807 -> Riven Cloud AS3258. The return direction showed Riven Cloud AS3258 -> CMIN2 AS58807 -> AS9808 -> China Mobile regional/access network.

The optimized route averaged 40.0 ms from China to Tokyo, with 39.8 ms best RTT and 0.0% final-hop packet loss. The return direction averaged 44.7 ms, with 44.6 ms best RTT and 0.0% final-hop packet loss.

The ordinary SoftBank transit baseline used China Mobile regional/access network -> AS9808 -> ordinary CMI AS58453 -> SoftBank AS17676 -> Riven Cloud AS3258 from China to Tokyo, and the same general chain in reverse from Tokyo back to China. It averaged 72.2 ms from China to Tokyo and 70.0 ms from Tokyo back to China, both with 0.0% final-hop packet loss.

For China Mobile customers, AS58807 is the signal to look for. The optimized sample uses CMIN2 instead of the ordinary AS58453/SoftBank transit path.

For the carrier-specific breakdown, read What is CMIN2? China Mobile International N2 and AS58807 explained.

How to read these MTR samples

The carrier sections above use cleaned sample MTR results collected on June 29, 2026. We publish carrier names, AS-level paths, direction, final-hop average RTT, and final-hop packet loss. We do not publish customer IP addresses, VPS IP addresses, router IPs, private IPs, hostnames, or full raw MTR output.

Treat these as point-in-time samples, not universal guarantees. The useful checks are simple: final-hop RTT, final-hop packet loss, visible AS path, and whether the route lands on the expected carrier network. In these samples, the optimized route had lower average final-hop RTT in both directions for all three carriers. The optimized samples also showed 0.0% final-hop packet loss, while the ordinary China Telecom baseline showed final-hop loss in this short sample.

Intermediate MTR packet loss, including 100% non-response on an intermediate hop, does not automatically mean real end-to-end packet loss. Many routers rate-limit or ignore ICMP while still forwarding customer traffic normally.

Use the ordinary SoftBank examples as a standard international transit baseline. SoftBank AS17676 is a major network. For this Tokyo-to-mainland-China use case, the carrier-specific premium paths fit better than a general transit path.

What customers actually feel

Most customers do not buy a route table. They buy a VPS because they want a website, API, control panel, game server, proxy service, development box, or internal tool to feel usable from mainland China.

The difference usually shows up in boring places: SSH stops feeling sticky, admin panels load without the first click hanging, and API calls from mainland China spend less time waiting on the network. It will not make every app fast, but it removes one common source of delay.

Peak-hour consistency is often the bigger win. A route that looks acceptable in the afternoon can become a problem in the evening if it depends on a congested international path. Matching China Telecom, China Unicom, and China Mobile to their own premium paths reduces that risk.

It does not remove every risk or guarantee the same latency for every province, office, mobile network, or residential line. Packet loss can still happen. The VPS starts from a better network position.

What China-optimized routing cannot guarantee

China-optimized routing improves path selection. It is not a physics exemption or a replacement for operational monitoring.

Performance can still depend on province, local ISP, last-mile quality, time of day, cross-border congestion, cable incidents, carrier routing changes, and the application itself. A user on weak Wi-Fi behind an overloaded local access network can still have a poor experience even if the international route is excellent.

MTR is a useful diagnostic tool, but it is not a full SLA. It shows a path sample at a point in time. That sample is valuable when it confirms the expected AS path and final-hop behavior, but it should not be treated as absolute proof that every future flow will behave identically.

The practical goal is better route selection: China Telecom through CN2/AS4809 and CTGNet/AS23764, China Unicom through AS9929 and China Unicom Global AS10099, and China Mobile through AS9808 and CMIN2/AS58807.

Choosing a Tokyo VPS for mainland China users

For a normal VPS buyer, CPU, RAM, NVMe storage, and transfer quota still matter. A busy application needs enough compute and disk performance. A high-traffic service needs a plan with enough monthly transfer. A production system needs backups and sensible operations.

For mainland China users, the network path can matter just as much.

A generic Japan VPS may be physically close to China, but physical distance is only one part of the route. The carrier path decides whether traffic enters the right Chinese backbone, whether the return direction is sensible, and whether the route remains stable when ordinary international transit gets busy.

Riven Cloud’s China-optimized Tokyo VPS routing is designed for customers who need that carrier-aware path: CTGNet/CN2 GIA for China Telecom, CUP for China Unicom, and CMIN2 for China Mobile.

Conclusion

China-optimized routing means matching each major mainland China carrier with its own premium path.

For Riven Cloud’s optimized Tokyo route, that means China Telecom traffic uses CN2/AS4809 domestically and CTGNet/AS23764 internationally, China Unicom traffic uses AS9929 and China Unicom Global AS10099, and China Mobile traffic uses AS9808 and CMIN2/AS58807.

That is what “three-network optimization” should mean in practice. It is not a slogan and it is not one generic overseas route. It is separate carrier engineering for China Telecom, China Unicom, and China Mobile.

If your users are in mainland China, the route can matter as much as CPU, RAM, and storage. Riven Cloud’s Tokyo route is built around that reality: China Telecom, China Unicom, and China Mobile each need their own path.

If you need a VPS with three-network optimized routing, you can order one at sa.net.