Test that your tunnel works

If the agent is running and the dashboard shows your device online, the tunnel is up — but until something on the public internet reaches you through it, you can't be sure. Five minutes, three commands.

Last updated 2026-05-22 · 3 min read

The 3-step walkthrough

1. Open a port and bind a real service

   The fastest one-liner uses python3, which is on macOS and Linux out of the box. Pick any port (we use 8080), bind it to :: (all interfaces, IPv4 + IPv6):

   python3 -m http.server 8080 --bind ::

   Leave it running. The terminal will print a request log for every hit.

   Prefer something prettier? Caddy is a one-liner too:

   caddy respond --listen :8080 "tunnel ok"

2. Curl your public IPv6 from another machine

   On a different device — your phone on mobile data is the cleanest test — run:

   curl -6 "http://[YOUR-IPv6-HERE]:8080/"

   Where YOUR-IPv6-HERE is the address shown on your dashboard. The square brackets around the IPv6 are required by curl. Example with a real address:

   curl -6 "http://[2001:df6:d2c0:1400::a1b2]:8080/"

   If you see a directory listing (from python3) or tunnel ok (from caddy), the tunnel is end-to-end functional.

   The terminal where the server is running will log the request, with the client's IPv6 — not your agent's. That confirms the packet really came over the public internet, not from localhost.

3. Try it from a browser too

   Paste this into the URL bar of any phone or laptop:

   http://[YOUR-IPv6-HERE]:8080/

   If the page loads, you can also reach the device from places that don't have curl — including your friend's iPhone halfway around the world.

No second device? Use our test page

If you don't have another machine to curl from, the hub itself can probe your IPv6+port from the public internet and report whether it could connect:

curl -s "https://wayangi.dalang.io/check?target=[YOUR-IPv6-HERE]:8080"

Expected on success:

OK · reached [2001:df6:d2c0:1400::42]:8080 in 23ms

Expected when nothing's listening on that port:

FAIL · couldn't reach [2001:df6:d2c0:1400::42]:8080 in 18ms — connection refused

Most common causes:
  1. The agent is offline — check `wayangi status`.
  2. Nothing is listening on port 8080 — start the service.
  3. The service bound to 127.0.0.1 / 0.0.0.0 only — bind to :: instead.

The probe is SSRF-safe — it only accepts targets inside our customer pool 2001:df6:d2c0:1400::/56, so it can't be used to scan other networks. Rate-limited to 5 checks/minute per source IP.

Common gotchas

Curl returns "Connection refused"

The agent's tunnel is up, but nothing is listening on the port you tried. Bring up the test server again (step 1) and make sure it printed Serving HTTP on :: — that double colon matters. If it printed Serving HTTP on 0.0.0.0, it bound to IPv4 only.

Curl returns "No route to host" or "Network unreachable"

The machine you're curling from doesn't have IPv6. Try the curl from a phone on cell data — mobile carriers all support IPv6. Or use the browser-on-phone trick from step 3.

The dashboard says my device is offline

The agent isn't connected to the hub. Check systemctl status wayangi on Linux, or run wayangi start in a terminal to see the error. Most common cause: outbound UDP/443 blocked by a firewall — open it.

Mac users: the dashboard works, but only ::10 in my /124 is reachable

Known limitation. macOS doesn't install the AnyIP local route automatically — only the prefix anchor is bound. For full prefix-delegation use, run on Linux. See the prefix-delegation guide for the full story.

Still stuck?

Mail [email protected] with:

• the IPv6 address from your dashboard,
• the exact error message (or "times out" / "connection refused"),
• your OS + agent version (wayangi --version).

We answer within one business day, Asia/Jakarta hours.

Next up

• Use all 16 / 256 / 4 096 / 65 536 / 2⁶⁴ addresses — once one address works, the rest of your prefix is free to bind to.
• Open the dashboard — rename the device, see traffic stats, rotate your token.