Provisioning a DMIT Tokyo node from zero: 45 minutes to a working CN2 GIA tunnel

This is the deploy walkthrough we run when we stand up a new DMIT Tokyo Premium node. It assumes you've already read DMIT Tokyo vs Lightsail Tokyo and decided CN2 GIA is what you want. If DMIT Tokyo is out of stock (it usually is), the substitutes are documented separately.

Forty-five minutes if nothing breaks. Two hours if you're being thorough about the hardening pass. Either way, the work is mostly sequential — there's not much you can parallelize on a single box.

Pre-flight: decisions you make before paying

Three decisions, made in order, before you open the order page.

Location. Tokyo. Not Hong Kong (post-2020 National Security Law makes HK data effectively reachable by mainland authorities, regardless of what the legal documents say). Not Los Angeles unless you've already exhausted Tokyo inventory — LA Premium is fine but adds ~110ms from mainland Chinese clients. Tokyo Premium is the default.

Plan tier. DMIT's Tokyo Premium ladder, in order of monthly bandwidth allowance:

Plan	Promo price	Monthly transfer	Best for
STARTER	~$119/yr	500 GB	1 user, no video
MINI	~$169/yr	1 TB	Default — 1-2 users with streaming
MICRO	~$239/yr	1.5 TB	Small family / group
MEDIUM	~$359/yr	2 TB	Heavy use, 4K streaming

Note the trap: DMIT throttles to 2-5 Mbps when you exceed the monthly cap. They don't bill overage like AWS Lightsail's $0.09/GB. The upside is no surprise invoices; the downside is throttled feels like the tunnel is broken. Round your traffic estimate up and buy one tier above what you think you need.

Bandwidth needs for a single user, real numbers from our deployments:

• Normal browsing + email + occasional video: 30-80 GB/month
• Single user streaming HD video through the tunnel: 150-400 GB/month
• Small group sharing (3-5 users): 400 GB - 1 TB/month
• Routing all device traffic 24/7: 1-3 TB/month

MINI covers most single-user cases. MICRO covers small groups.

Promo codes. Do not pay sticker price. Annual plans go on sale around Singles Day (11.11), Black Friday, Chinese New Year, and Mid-Autumn — often at 50% off. The promo locks in for up to three renewal cycles, so a well-timed buy is effectively a 50% discount for three years.

Sources for current codes:

• Official DMIT Telegram: t.me/s/dmit_inc
• LowEndTalk DMIT threads: lowendtalk.com search "DMIT"
• Nodeseek (Chinese community, often has codes first): nodeseek.com

If you don't see a 50% promo right now, wait. The cost of waiting is two to six weeks; the cost of paying sticker is twice the annual rate locked in.

Buying the box

1. Open the order page. Pick Tokyo Premium MINI (or whichever tier).
2. Apply the promo code at checkout.
3. Choose Debian 12 as the OS template. Avoid Ubuntu (DMIT's Ubuntu images can lag on security updates) and avoid CentOS Stream (Debian is the path of least friction).
4. Pay. Card and PayPal are the fast paths. Crypto (USDT/BTC) is supported if you want a different paper trail.
5. Enable 2FA in the DMIT client area immediately. The client area controls reinstall, console access, and billing — 2FA is non-negotiable.

DMIT provisions in 5-15 minutes. You'll receive an email with the public IPv4, a root password, and an IPv6 /64 subnet.

First SSH

DMIT ships boxes with password authentication enabled and root login allowed. This is the muscle-memory trap if you've come from AWS Lightsail: there's no key-based login by default, and there's no managed firewall in front of the box.

First connection:

ssh root@<DMIT-IP>
# enter the root password from the provisioning email

If the shell prompts, you're in. Don't install anything, don't open ports, don't configure anything until the hardening pass is done. The box is wide open until you close it.

Hardening (mandatory before anything else)

The next four blocks run as root on the new server. Each addresses a specific exposure that's open by default on DMIT.

Swap to SSH key + change port + kill password auth

# Paste your public key
mkdir -p /root/.ssh && chmod 700 /root/.ssh
cat > /root/.ssh/authorized_keys <<'PUBKEY'
ssh-ed25519 AAAA...your-key-here... comment
PUBKEY
chmod 600 /root/.ssh/authorized_keys

# Harden sshd: non-standard port, no password auth, v4 only
cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak.$(date +%Y%m%d)
sed -i 's/^#\?Port .*/Port 22022/' /etc/ssh/sshd_config
sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin .*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^#\?PubkeyAuthentication .*/PubkeyAuthentication yes/' /etc/ssh/sshd_config
sed -i 's/^#\?AddressFamily .*/AddressFamily inet/' /etc/ssh/sshd_config

# Verify config before restart
sshd -t && echo "OK" || echo "BROKEN — fix before restart"

systemctl restart ssh

Critical: open a second terminal and verify key login on the new port before you close the original password session. If the key login fails and you've already closed the original session, you'll need DMIT's VNC console (client area → services → your VPS → console) to recover. The two-terminal pattern costs nothing and saves an hour of console-recovery work the one time you typo a config line.

# In a second terminal:
ssh -p 22022 -i ~/.ssh/id_ed25519 root@<DMIT-IP>

If this works, close the first session.

Firewall (UFW)

DMIT has no front-of-box firewall like Lightsail's. UFW is your only inbound filter.

apt-get update && apt-get install -y ufw
ufw default deny incoming
ufw default allow outgoing
ufw allow 22022/tcp
ufw allow 443/tcp
ufw --force enable
ufw status verbose

Two ports allowed: SSH (whatever port you picked above) and 443 for the VPN. Everything else dropped.

Kill IPv6

DMIT ships dual-stack. If your tunnel design is IPv4-only — and most residential-proxy chains are — v6 will leak around the IPv4 egress. Kill v6 at the kernel:

cat > /etc/sysctl.d/99-disable-ipv6.conf <<'EOF'
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
EOF
sysctl -p /etc/sysctl.d/99-disable-ipv6.conf

# Verify — all three return 1
cat /proc/sys/net/ipv6/conf/all/disable_ipv6
cat /proc/sys/net/ipv6/conf/default/disable_ipv6
cat /proc/sys/net/ipv6/conf/lo/disable_ipv6

The full lockdown (ip6tables, daemon audit) is covered in DMIT ships dual-stack: the IPv6 leak. At minimum, the sysctl block here closes the kernel-level exposure.

Time sync (Reality requires it)

apt-get install -y chrony
systemctl enable --now chrony
chronyc tracking | grep "Leap status"  # should report "Normal"

Reality uses TLS 1.3 timestamp verification. If the server clock drifts more than about a minute, Reality handshakes silently fail and clients see "connection timeout" with no useful error. Chrony is mandatory.

Auto security updates and brute-force protection

apt-get install -y unattended-upgrades fail2ban

# Configure auto-updates
dpkg-reconfigure -plow unattended-upgrades  # answer Yes

# Configure fail2ban for the new SSH port
cat > /etc/fail2ban/jail.local <<'EOF'
[DEFAULT]
bantime = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
port = 22022
EOF
systemctl enable --now fail2ban

Limit journald retention

Default journald holds logs for months at a 4 GB cap. For a VPN endpoint, that's a long record of "this server was contacted from this IP at this time." Cap it:

mkdir -p /etc/systemd/journald.conf.d
cat > /etc/systemd/journald.conf.d/retention.conf <<'EOF'
[Journal]
SystemMaxUse=50M
MaxRetentionSec=7day
EOF
systemctl restart systemd-journald

Verify the hardening block

ufw status | grep -E "22022|443"           # both should be ALLOW
cat /proc/sys/net/ipv6/conf/all/disable_ipv6  # 1
chronyc tracking | grep "Leap status"       # Normal
systemctl is-active fail2ban                # active
grep PasswordAuthentication /etc/ssh/sshd_config | grep -v "^#"  # no

All five should pass. If any fails, stop and fix before installing anything.

Install Xray + VLESS Reality

Use the official install script. It's signed, maintained, and the simplest path:

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
xray version

Generate Reality keypair + UUID + short ID

# Reality keypair (save both — private goes in server config, public goes in client VLESS link)
xray x25519

# Short ID (16 hex chars)
openssl rand -hex 8

# Client UUID
cat /proc/sys/kernel/random/uuid

Write these four values down. You'll paste them into the config in the next step and into the client subscription after that.

Write the Xray config

mkdir -p /usr/local/etc/xray
cat > /usr/local/etc/xray/config.json <<'EOF'
{
  "log": {
    "loglevel": "warning",
    "access": "none"
  },
  "dns": {
    "servers": [
      { "address": "https+local://1.1.1.1/dns-query", "queryStrategy": "UseIPv4" },
      { "address": "https+local://8.8.8.8/dns-query", "queryStrategy": "UseIPv4" }
    ],
    "queryStrategy": "UseIPv4"
  },
  "inbounds": [
    {
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "PASTE-UUID-HERE",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "www.bing.com:443",
          "xver": 0,
          "serverNames": ["www.bing.com"],
          "privateKey": "PASTE-PRIVATE-KEY-HERE",
          "shortIds": ["PASTE-SHORT-ID-HERE"]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"]
      }
    }
  ],
  "outbounds": [
    { "tag": "direct", "protocol": "freedom", "settings": { "domainStrategy": "UseIPv4" } },
    { "tag": "block", "protocol": "blackhole" }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      { "type": "field", "ip": ["geoip:private"], "outboundTag": "block" }
    ]
  }
}
EOF

# Replace the three placeholders
nano /usr/local/etc/xray/config.json

Replace PASTE-UUID-HERE, PASTE-PRIVATE-KEY-HERE, and PASTE-SHORT-ID-HERE with the values you generated. Save and exit.

This config does direct egress from the DMIT box. If you want to chain through a residential proxy for IP-reputation work, see DMIT + Webshare egress chain for the extra outbound block and routing rules.

Start Xray

systemctl enable --now xray
systemctl status xray | head -20  # should say "active (running)"
journalctl -u xray --no-pager -n 20  # should be quiet, no errors

If status errors, test config syntax:

xray test -config /usr/local/etc/xray/config.json

SNI choice (the gotcha that costs you the deploy)

The dest and serverNames fields in realitySettings decide which domain Reality impersonates during the TLS handshake. This choice is load-bearing. The wrong domain gets your endpoint actively probed within hours from mainland Chinese network ranges.

Ranking, safest to riskiest, for endpoints serving traffic from mainland China:

SNI	Why it works	Risk
www.bing.com ⭐	Bing operates inside mainland China legally. Blocking would have massive collateral damage.	None — use this
www.microsoft.com	Heavily used by businesses inside China, hard to block without breaking enterprise tooling.	Low
www.apple.com	Same logic as Microsoft.	Low
www.cloudflare.com	Cloudflare ranges themselves get inspected.	Medium
www.amazon.co.jp	Reasonable for Japan but amazon.* domains attract active probing.	Medium
Any .cn domain	Reachable from China but draws inspection.	High

We've seen a Tokyo endpoint deployed with www.amazon.co.jp get probed 327 times from a single Chinese provincial network range within 24 hours of deployment. We hot-swapped to www.bing.com, rotated the Reality keypair, and the probes stopped within an hour. Lesson: pick Bing as the default. Escalate to Microsoft or Apple only if Bing specifically gets a problem.

The rule for any domain you pick: it must be (1) reachable from mainland China without DNS or routing interference, (2) a real HTTPS host (Reality probes verify the TLS fingerprint matches), (3) not a known VPN-provider-favored domain.

Wire the client subscription

Build the VLESS link in this exact format. Shadowrocket and most clients are picky about parameter order:

vless://<UUID>@<DMIT-IP>:443?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.bing.com&fp=chrome&pbk=<PUBLIC-KEY>&sid=<SHORT-ID>&type=tcp#VPN-Tokyo-DMIT

Replace the four placeholders with the values from your setup. The # fragment is the label the client displays — pick something distinct so you can tell this node apart from others in your list.

How to feed the link to your client depends on the client. The straightforward path: paste the link directly into the client's "Add Node" or "Import" flow. The scalable path for multiple devices: stand up a subscription file on a separate node, list the VLESS lines in a base64-encoded file, and point the client's "Subscribe" feature at it. Subscription rotation is a bigger topic — see VLESS Reality clients on macOS and Windows for the client-side wiring.

Verification

Three checks from the client after connecting:

1. Exit IP — curl https://ifconfig.co from the client should return the DMIT IP. If you've added the residential proxy chain, it should return the Webshare IP instead. Either way, it should not return your real client IP.
2. DNS — dnsleaktest.com extended test. Should show a single resolver (Cloudflare 1.1.1.1 or Google 8.8.8.8 via DoH on the server), not your local ISP.
3. WebRTC — browserleaks.com/webrtc should not reveal your local IP. If it does, that's a client-side issue (disable WebRTC in the browser) not a server issue.

If all three are clean, the tunnel is working.

Bandwidth tracking on the server

DMIT has no API equivalent to AWS Lightsail's lightsail:GetInstanceMetricData. You track bandwidth on the server itself:

apt-get install -y vnstat
systemctl enable --now vnstatd

# Wait a minute, then:
vnstat -i eth0       # daily summary
vnstat -m            # monthly summary

vnstat -m is what you check against your DMIT plan's monthly cap. If you're approaching the cap, either upgrade the plan or wait for the cycle to roll over — DMIT does not bill overage, but throttling kicks in immediately.

Maintenance cadence

After deployment, the recurring work:

Task	Cadence	Why
Check bandwidth usage	Weekly	Avoid throttle surprise
Rotate Reality keypair	Every 90 days, or immediately if probed	Limits the value of any captured keypair
Audit journal for probes	Monthly	journalctl -u xray | grep -i reject
Apply security updates	Daily (automatic via unattended-upgrades)	Kernel and userspace patches
Renew DMIT plan	Annually (lock 3 years if pricing is good)	Avoids re-buying at sticker
Re-run leak audit	Quarterly	Catches drift from kernel updates, config changes

The 90-day Reality keypair rotation is conservative. It's there because if a keypair leaks (server compromise, config in a backup, screenshot in a chat) the attacker can continue impersonating your endpoint until you rotate. Tighter rotation (30 days) is fine if you have client-side automation for distributing the new VLESS link.

What this doesn't cover

This is the single-node deploy. A few topics that compound from here:

• Multi-node and subscription rotation — running three or more nodes, having clients automatically switch based on probe results, and rotating the subscription URL when a token gets pushed to public lists.
• Residential proxy egress — chaining the DMIT box through a residential proxy for IP-reputation work. Covered in DMIT + Webshare egress chain.
• DMIT-specific quirks at scale — what happens when you run five DMIT boxes, how the affiliate billing aggregates, how to handle a provider-side outage. Mostly operational rather than technical.
• GFW response when your IP gets flagged — symptoms, signals in the journal, and the keypair-rotate playbook. We're publishing this as a separate piece.

For the single-node deploy that's good enough to be daily-drivable, the steps above are the whole job. The total compute time on a fresh box is around 45 minutes if you don't get caught up debugging SSH lockout or SNI choice. If you do, give yourself two hours.

If you're standing up a multi-node setup, want a second opinion on SNI choice for a specific deployment, or need the chain wired through a residential proxy for IP-reputation reasons, that's the kind of work we do at /services.