Testing Your Connection

Torus Echo — Connectivity Test Service

Once you have configured your VPN connection, verify it is working by connecting to the Torus Echo service. This is a dedicated test endpoint that is always available on the Torus mesh network.

Test Endpoint

Service	Address	Description
HTTP	`http://10.254.100.102`	Web page confirming connectivity with latency measurement
Ping (ICMP)	`10.254.100.102`	Basic reachability check
JSON API	`http://10.254.100.102/ping`	Machine-readable status with your tunnel IP
Health Check	`http://10.254.100.102/health`	Service uptime

Testing via Web Browser

The easiest way to test your connection:

Connect to the Torus VPN using your WireGuard configuration
Open a web browser
Navigate to http://10.254.100.102
You should see a dark-themed page with a pulsing green ring and the text “Connected to Torus”

The page automatically measures your round-trip latency (average of 4 samples) and displays your WireGuard tunnel IP address.

Testing via Command Line

Using ping

ping 10.254.100.102

Expected output for a user connected to the London hub:

PING 10.254.100.102 (10.254.100.102): 56 data bytes
64 bytes from 10.254.100.102: icmp_seq=0 ttl=64 time=12.3 ms

Using curl (HTTP)

curl http://10.254.100.102/ping

Expected output:

{"status":"ok","remoteIp":"10.254.100.109","rtt":"0.01","node":"10.254.100.102","hub":"eu-west-2"}

The remoteIp field shows your WireGuard tunnel IP address — useful for verifying you are connecting from the correct interface.

Expected Latency

The echo service runs on the London (eu-west-2) hub. Your latency depends on physical distance:

Your Location	Expected RTT
London / UK	5–15 ms
Continental Europe	20–40 ms
US East Coast	70–90 ms
Middle East (Dubai)	100–130 ms
US West Coast	130–160 ms
Asia Pacific	150–250 ms

Troubleshooting

Cannot reach 10.254.100.102

Check VPN is connected — run sudo wg show and verify latest handshake is within the last 2–3 minutes. Even if your client shows connected, it could be lying to you.
Check your AllowedIPs — your WireGuard config must include the Torus subnets. For Plus/Pro users with 0.0.0.0/0, all traffic is tunnelled. For Basic users, ensure 10.254.100.0/24 is included.
Branch router users — if you connect through a MikroTik on your LAN, ensure you have a masquerade NAT rule for LAN traffic going out the WireGuard interface. Without this, your packets arrive with a private LAN IP that the echo service cannot route back to.
Firewall rules — ensure your local network allows outbound UDP on port 13231 (the WireGuard listen port for all Torus hubs).
Cross-hub users — if you are connected to Ohio or Frankfurt, reaching the echo service requires working inter-hub routing. Try pinging your own hub gateway first (e.g. 10.254.17.1 for Ohio).

High Latency (>300ms)

Check your internet connection quality — packet loss and jitter on your upstream ISP link will compound inside the tunnel.
If you are far from the London hub geographically, high latency is expected. See the table above for reference values.
If latency is significantly higher than expected for your region, try restarting your WireGuard interface.

Latency Shows 0ms in Browser

Your browser is serving a cached version of the page. Hard refresh with Ctrl+Shift+R (Windows/Linux) or Cmd+Shift+R (macOS).

Still Not Working?

See the Connection Issues guide in the Troubleshooting book for a step-by-step diagnostic walkthrough, or contact support via the Forum.

Technical Details

The Torus Echo service is a lightweight Node.js HTTP server running on the FreeBSD application server (10.255.9.11). It listens on a dedicated WireGuard tunnel IP (10.254.100.102) within the London hub’s user subnet.

HTTP (port 80) — connectivity confirmation page with client-side latency measurement
ICMP — responds to ping for basic reachability testing
Firewall — accepts only ICMP and HTTP from the Torus network (10.254.0.0/16). Not reachable from the public internet.

The IP address 10.254.100.102 is permanently reserved for this service and will never be allocated to users.