CellRoute is intentionally a TCP proxy. This matches SOCKS5 CONNECT, standard HTTP proxy requests and HTTPS CONNECT tunnels, but it does not include every transport an application may choose.
TCP has a connection to bind
For each accepted request, CellRoute creates a target TCP Socket from the Android cellular Network and relays bytes between two established connections. Timeouts, half-close behavior and connection accounting all operate around that stream model.
UDP needs a different relay design
UDP is message-oriented and has no TCP-style connection. SOCKS5 defines UDP ASSOCIATE as a separate command with its own relay framing and security considerations. CellRoute does not implement it and does not expose a generic UDP forwarder.
QUIC normally uses UDP
Modern browsers and services may prefer HTTP/3 over QUIC, which commonly runs over UDP. That traffic cannot pass through CellRoute’s TCP-only path. A browser may fall back to HTTP/2 or HTTP/1.1 over TCP, or it may need a documented setting that disables or bypasses QUIC for the test.
The exact control depends on the client. CellRoute does not modify the client automatically.
Verification must be transport-aware
When testing, use an application and destination known to support TCP through the configured proxy. Do not infer that every request is proxied just because one webpage loads. DNS behavior, application proxy support and alternative transports can produce mixed results.
This limit is also why CellRoute is not a transparent gateway or full-device protection tool: it handles the explicitly configured TCP path and leaves other traffic outside that boundary.