# TUIC monitoring

To monitor a TUIC server, do what a TUIC client does: complete the QUIC handshake over UDP, then authenticate with your UUID and password. TunnelHQ runs that exchange from outside, with the congestion-control and ALPN settings in your `tuic://` link, every 1 to 5 minutes by plan, and alerts you in 20 channels when it fails.

[Start Free Trial](https://app.tunnelhq.com/register) [View the API docs](https://docs.tunnelhq.com/api/)

## 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](https://tunnelhq.com/test/), or the API, and TunnelHQ identifies everything it needs:

```
tuic://5f8d7a3e-1c2b-4d5e-9f6a-7b8c9d0e1f2a:Str0ngPass@vpn.yourdomain.com: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](https://tunnelhq.com/hysteria2-monitoring/) 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-...:Str0ngPass@vpn.yourdomain.com: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.

| Plan | Tunnels | Check interval | Price |
| --- | --- | --- | --- |
| Free trial | 14 days free on every plan. Your card is charged on day 15, and you can cancel any time before. |
| Starter | 20 | 5 min | $12/mo or $84/yr |
| Pro | 100 | 2 min | $39/mo or $276/yr |
| Business | 500 | 1 min | $99/mo or $756/yr |

[See the full plan comparison](https://tunnelhq.com/pricing/)

[Start Free Trial](https://app.tunnelhq.com/register) [Test a config free](https://tunnelhq.com/test/)

## Read more

-   [TUIC in the docs](https://docs.tunnelhq.com/protocols/v2ray-xray/)
-   [Hysteria2 monitoring](https://tunnelhq.com/hysteria2-monitoring/)
-   [VLESS monitoring](https://tunnelhq.com/vless-monitoring/)

## TUIC monitoring questions

### Does TunnelHQ support TUIC v5?

Yes. v5 is the current spec implemented by sing-box and modern tuic-server deployments, and it's what the checker speaks. Paste the URI your client uses and TunnelHQ tests exactly that.

### Is an ICMP ping or UDP port probe ever enough for TUIC?

No. Ping tests the host, not the service. UDP probes can't distinguish a healthy TUIC server from a dead one because closed UDP ports frequently return nothing. Only a completed QUIC handshake plus TUIC authentication proves the server works.

### Are both udp\_relay\_mode values supported?

Yes. `native` and `quic` are both parsed from the URI and honored during the check.

### Can I test a TUIC server once without an account?

Yes. The [free VPN tester](https://tunnelhq.com/test/) runs a one-off TUIC check from the paste box. No signup. If you also run [VLESS](https://tunnelhq.com/vless-monitoring/) or other Xray-family servers, the same tester covers those too.

Source: https://tunnelhq.com/tuic-monitoring/