TUIC monitoring

Why a port check can't see TUIC at all

TUIC rides entirely on QUIC over UDP. There is no TCP socket to probe, so a classic TCP port check has nothing to connect to. And UDP "port checks" are close to meaningless: a dead UDP port often returns nothing at all (or an ICMP unreachable that gets filtered), so scanners report open|filtered whether your server is healthy, misconfigured, or gone.

It gets worse. TUIC is designed to blend in with HTTP/3 traffic. It negotiates ALPN h3 and looks like any other QUIC endpoint on the wire. Even a probe with a real QUIC stack only proves that something completed a TLS 1.3 handshake, because TUIC's own authentication happens after QUIC is established. Your server can terminate QUIC perfectly and still reject every client:

• The UUID was rotated or deleted server-side but clients weren't updated
• The password no longer matches
• The TLS certificate expired. QUIC bakes TLS 1.3 into the transport, so certificate validation failures kill the connection before TUIC auth even starts
• The ALPN value changed on the server and no longer matches what clients send
• An ISP or upstream network started throttling or dropping QUIC/UDP on that path

Every one of those leaves ping and port monitors green while real users can't connect.

What a real TUIC check verifies

TunnelHQ's checker completes both layers of the connection, in order:

• QUIC layer. UDP reachability, the TLS 1.3 handshake inside QUIC, certificate validity, SNI, and ALPN negotiation
• TUIC layer. The protocol's authenticate exchange using your UUID and password. Only a server that accepts your credentials counts as "up"

Because the check terminates a genuine QUIC connection, the measured latency is the real handshake round-trip your users experience, not a ping time.

URI auto-detection

Paste a standard tuic:// URI into the dashboard, the free protocol tester, or the API, and TunnelHQ identifies everything it needs:

tuic://5f8d7a3e-1c2b-4d5e-9f6a-7b8c9d0e1f2a:[email protected]:443?
  congestion_control=bbr&
  alpn=h3&
  udp_relay_mode=native&
  sni=vpn.yourdomain.com#Tokyo-01

From this single URI, TunnelHQ extracts:

• UUID (5f8d7a3e-...) and password. TUIC's two-part credential
• Endpoint (vpn.yourdomain.com:443)
• Congestion control algorithm (bbr, cubic, or new_reno)
• ALPN (h3)
• UDP relay mode (native or quic)
• SNI for the TLS handshake

No manual field mapping. The URI is the config.

Congestion control, ALPN, and UDP relay mode

TUIC's appeal is performance tuning: BBR congestion control keeps throughput high on lossy links, and udp_relay_mode=native forwards UDP without full-quic encapsulation overhead. These are also settings that must agree between server and client. A monitor that probes with generic defaults can pass while your actual clients, configured differently, fail. TunnelHQ uses the parameters from your URI, so a green check means your real client config works.

Running Hysteria2 alongside TUIC? Both are QUIC-based, but they authenticate differently. Hysteria2 uses password auth with optional Salamander obfuscation, TUIC uses UUID+password. TunnelHQ monitors each with its own protocol-correct check.

Common TUIC failure modes TunnelHQ catches

• UUID or password rotation that never reached client configs
• TLS certificate expiry. Renewals that silently failed surface here first
• SNI or ALPN mismatch after a server-side config edit
• Regional QUIC throttling. UDP interference that only affects some ISPs or countries
• Server process crashed while the host still answers ICMP ping
• NAT or firewall state expiry silently breaking the UDP path

Pin a tunnel to several countries (Pro and Business), so a failure in one country with passes elsewhere points at path-level QUIC blocking rather than a dead server.

Automate checks with the REST API

TUIC is a URL-based protocol in TunnelHQ's API. One field, the URI:

curl -X POST https://app.tunnelhq.com/api/v1/check/public \
  -H "Content-Type: application/json" \
  -d '{
    "protocol": "tuic",
    "url": "tuic://5f8d7a3e-...:[email protected]:443?congestion_control=bbr&alpn=h3"
  }'

The response includes handshake latency and, on failure, whether the QUIC layer or the TUIC auth layer broke. That distinction alone saves most debugging sessions.

What a failed check tells you

A failed check comes with a message that says where to look. For TUIC, as for the other V2Ray and Xray share-link protocols, there are two to know.

• Tunnel established - Internet is stuck. The proxy connection worked, but traffic through it didn't reach the internet. Check the server's routing and NAT, its DNS, and whether its outbound traffic is blocked.
• Tunnel unreachable. The connection didn't come up. Check that the server is running, that the host and port in the link are reachable, and that the link's credentials and transport settings (such as sni) match the server's.

The API response for a failed TUIC check also says whether the QUIC layer or the TUIC authentication layer broke.

Need this on a schedule?

The one-off test tells you a server works right now. TunnelHQ runs the same QUIC handshake and TUIC auth check every 1 to 5 minutes by plan against your whole fleet, and fires Slack, email, Telegram, Discord, or webhook alerts as soon as a failed handshake is confirmed. Before your users notice.

Pricing for TUIC monitoring

All plans include TUIC monitoring.

See the full plan comparison

Read more

• TUIC in the docs
• Hysteria2 monitoring
• VLESS monitoring