CONNECT-UDP lets an HTTP client ask a compatible proxy to relay UDP payloads to a specified host and port. Defined by RFC 9298, it uses an HTTP request to establish a bounded tunnel and HTTP Datagrams to carry UDP data. The proxy opens a UDP socket on the client’s behalf, then converts datagrams in both directions while the associated request stream remains active.
The central engineering question is not whether UDP can fit through HTTP; it is whether the proxy serves only authorised destinations without becoming a network bypass or amplification service. A successful tunnel response does not prove the target is reachable, and an authenticated client is not necessarily permitted to reach every private address or port. Current security rules also matter: RFC 9931, published in March 2026, forbids optimistic UDP payload sending during an HTTP/1.x upgrade, revising the original RFC 9298 allowance.
This is a guide to real HTTP, QUIC, MASQUE and security engineering used by possible contemporary agent systems, not a claim that artificial superintelligence exists. It traces the request and Datagram framing, target validation, limits, connection lifetimes, current standards updates, exact numerical scenarios and independent transfer checks. All worked deployment numbers are explicitly invented teaching cases rather than measurements of a live eduKate network.
Contents and reading routes
To understand the actual tunnel: its purpose, the current standards, target encoding, HTTP version negotiation, Datagram framing, Quarter Stream ID, Context ID and proxy DNS trust.
For secure operations: source filtering, tunnel lifecycle, delivery behaviour, packet sizing, capacity mathematics, abuse controls, the 2026 HTTP/1.x change, error diagnosis and buffering bounds.
For readers building agent-connected systems: authority separation, neighbouring protocols, verification metrics, independent transfer, boundaries, FAQs, primary RFC sources and verified eduKate routes.
What a CONNECT-UDP tunnel actually connects
A typical HTTP proxy receives a request and forwards an HTTP operation or establishes a TCP tunnel using CONNECT. UDP is different because it carries independent datagrams without a TCP connection handshake. CONNECT-UDP gives the client a way to request that UDP payloads be relayed through an HTTP proxy to a named UDP target. The initiating request defines the destination and the HTTP stream supplies a lifetime for the tunnel.
The target is a UDP host-and-port pair, not another HTTP page. Suppose an approved agent-control application needs to communicate with its own UDP-based service at telemetry.example.test port 443. The example domain is fictional. The client connects to an approved proxy over HTTP, requests a tunnel to that target, and then sends UDP data inside the negotiated HTTP Datagram mechanism. The proxy sends the extracted bytes onward as UDP payloads.
This does not make UDP reliable or ordered. If the encapsulated transport provides unreliable datagrams, loss and reordering can still happen. Even if the HTTP transport falls back to a reliable Capsule stream, that changes the delivery characteristics of the outer transport but does not turn a UDP application into an ordinary HTTP request. Application protocols must still handle their own semantics.
The terms client, proxy and target name three different authorities. The client decides to request a destination. The proxy decides whether that request is allowed, opens the socket and enforces resource policy. The target receives packets whose apparent source is the proxy, not the original HTTP client. That identity shift is a major reason arbitrary open tunnelling is unsafe.
The standards family and its current 2026 update
RFC 9298, published in August 2022, specifies Proxying UDP in HTTP and the connect-udp upgrade token. RFC 9297 supplies HTTP Datagrams and the Capsule Protocol used to carry their payloads. These are distinct layers: the first defines what a UDP proxy request means, while the second describes the framing and transport machinery used by compatible HTTP extensions.
RFC 9484, published in October 2023, defines CONNECT-IP for forwarding arbitrary IP packets and updates the well-known MASQUE URI registration shared with the earlier UDP specification. IP proxying is not the same operation as UDP proxying to one target. A design document should not quietly treat an IP tunnel as an unrestricted variant of a single UDP socket; the security and routing scope differs.
RFC 9931, published in March 2026, adds security requirements for optimistic protocol transitions in HTTP/1.1 and explicitly updates RFC 9298. It preserves the possibility of optimistic UDP payloads only on HTTP/2 or later, while forbidding them during HTTP/1.x upgrades. This is a meaningful current requirement, not an optional implementation taste, because unconfirmed HTTP/1.1 upgrade data can create request-smuggling risks.
Read the current RFC index rather than stopping at an old cached snippet. Standards can be updated without renumbering the original explanatory sections, and a configuration that followed an older example may become non-compliant. The precise references are linked below so a reviewer can distinguish the base behaviour, a later URI-related update and the 2026 security amendment.
The target host and port arrive through a URI Template
RFC 9298 identifies the UDP proxy by an absolute URL and uses a configured URI Template to put the target_host and target_port in the request target. The template determines exactly how those variables appear. It is not safe to assume that every compatible proxy uses a guessed fixed path. A client must expand the template actually supplied or agreed for that proxy.
Both variables must be present and nonempty, and target_port must be a decimal port integer from one through 65,535 inclusive. Target_host can describe a DNS name, IPv4 address or IPv6 literal under the RFC’s formatting rules. A zero port, missing host or unsupported zone identifier is not an invitation to guess a default target. Reject invalid destinations before constructing a tunnel.
For an IPv6 literal, colons inside the target_host are percent-encoded when expanded into the URL. The illustrative address 2001:db8::42 therefore appears as 2001%3Adb8%3A%3A42 in the variable. This is URI encoding, not a change to the IPv6 address itself. A proxy must decode and validate the intended destination rather than trust a literal string that merely looks address-like.
Separate syntax from authorisation. A perfectly encoded IP literal can still be forbidden because it is loopback, link-local, multicast, broadcast or an administrative network. An allowed hostname can later resolve to a prohibited IP address. Robust proxies validate the resolved destination and network policy at the point they create the UDP socket, not just the text of the original URL.
How HTTP/1.1, HTTP/2 and HTTP/3 establish the request
HTTP/2 and HTTP/3 use extended CONNECT mechanisms to associate a tunnel with a multiplexed request stream. The request conveys a protocol token and the proxy target under the appropriate version-specific rules. A successful response establishes the proxy’s willingness to relay datagrams. The HTTP connection may carry other streams with separate permissions; one accepted tunnel does not authorise unrelated requests.
HTTP/1.1 uses Upgrade rather than the same extended CONNECT framing. Its protocol transition is sensitive to whether the upgrade has actually been accepted. Unlike HTTP/2 and HTTP/3, HTTP/1.1 does not give each concurrent request a separate stream identifier for safe multiplexing. That difference is central to RFC 9931’s concern about optimistically sending tunnel payload bytes before a response confirms the transition.
A troubleshooting trace should record the negotiated HTTP version, request target, protocol token, relevant capsule negotiation and exact response state. A report that says UDP tunnel accepted without the transport and status context hides important differences. When a proxy replies with an unsuccessful HTTP response, the client must abort the proxying request rather than assume UDP forwarding is available.
A tunnel response is not a reachability proof. Because UDP does not establish a handshake with the remote endpoint, the proxy can open a socket and return success without ever receiving a target packet. When target_host is a DNS name, RFC 9298 requires the proxy to perform DNS resolution before replying and to reject the request if resolution fails. The remote service may still be down.
HTTP Datagrams are associated with a particular request
RFC 9297 provides a convention for conveying datagrams within an HTTP connection. An HTTP Datagram is bound to a request that explicitly defines how datagrams are used. Ordinary GET and POST do not acquire datagram semantics merely because bytes arrive on the connection. Receiving an HTTP Datagram for a request that does not define those semantics is a protocol error, with the relevant abort behaviour specified by the transport.
Under HTTP/3, QUIC DATAGRAM frames can provide the outer unreliable carriage. Each HTTP/3 Datagram includes a Quarter Stream ID indicating which HTTP request stream it belongs to. This association allows multiple eligible requests to share a connection without mixing datagrams. A UDP proxy must still enforce request-specific permissions: a valid stream ID is a routing label, not a new authorisation token.
The HTTP Datagrams convention can also operate over the Capsule Protocol, including HTTP/2 and HTTP/1.x where native unreliable HTTP/3 datagrams are not available. A Capsule is delivered in the request stream’s reliable framing. That compatibility is useful but can change timing and loss-recovery behaviour, especially if a UDP-based inner transport is also trying to recover from losses.
Implementers should keep the two framing layers clear. An HTTP/3 Datagram identifies its request using the Quarter Stream ID, then the CONNECT-UDP payload format further identifies a Context ID. Those numbers serve different jobs. A receiver that mistakes a Context ID for a stream identifier can misroute or discard data even while the HTTP request itself appears valid.
Worked encoding: Quarter Stream ID is one fourth of a request ID
HTTP/3 client-initiated bidirectional request stream IDs are multiples of four. The Quarter Stream ID field in an HTTP/3 Datagram is the actual stream ID divided by four. If the HTTP request lives on stream ID 12, the corresponding Quarter Stream ID is three. For request stream ID 40, the Quarter Stream ID is ten. These are exact integer relationships from the framing specification.
Suppose a fictional client uses request streams 12 and 40 for two allowed UDP tunnels. An incoming HTTP/3 Datagram with Quarter Stream ID three belongs to stream 12, not to a target named three and not to the third UDP packet. A Datagram with Quarter Stream ID ten belongs to stream 40. The parser must validate this association against the streams actually permitted to carry datagrams.
The framing uses variable-length integer encoding. Encoded field length may vary with values, so do not invent a constant byte overhead for all possible stream identifiers. The fact that an illustration uses small IDs does not prove a network’s wire overhead is always one byte. For sizing, inspect the actual QUIC and HTTP Datagrams encodings and the negotiated packet size.
A proxy should reject malformed request associations and apply bounded handling to a datagram that arrives before its corresponding request is known. RFC 9297 permits limited buffering or dropping in specified circumstances. Unlimited buffering of unknown identifiers would allow a peer to consume memory without successfully establishing authorised tunnels.
CONNECT-UDP Context ID and payload semantics
RFC 9298 defines an HTTP Datagram payload format for UDP proxying. It starts with a Context ID, encoded as a QUIC variable-length integer, followed by UDP Proxying Payload bytes. Context ID zero identifies ordinary UDP payloads. The payload for that context is the UDP data portion, not an HTTP message or an arbitrary new target instruction.
That distinction matters when constructing and decoding packets. The proxy takes the UDP Proxying Payload associated with an accepted tunnel and forwards it on the appropriate UDP socket. It does not reinterpret each datagram as a new URL or let the sender override target_host and target_port midstream. The control-plane request selected the destination; the data plane carries bytes under that selection.
RFC 9298 limits the length of payloads for the default UDP context consistently with UDP’s format, and the outer HTTP transport may impose a stricter practical maximum. A program should check those bounds before forwarding. Invalid context IDs and oversized payloads require the specified drop or bounded buffering behaviour rather than silent reinterpretation as application commands.
For a debugging demonstration, write down a pair: request stream 12, Context ID zero. The stream number selects the authorised HTTP proxy request, while Context ID zero says the following bytes are ordinary UDP payload for that tunnel. If a second request exists on stream 40, it needs its own association, regardless of whether that second tunnel also uses Context ID zero.
DNS resolution is part of the proxy’s trust boundary
When the requested target is a DNS name, the proxy resolves it before acknowledging the request. That resolution happens in the proxy’s network context, which may have different private zones or address reachability from the client’s network. A client-supplied name that looks public could resolve to an address the client would never reach directly. This is why DNS and destination policy are inseparable for a proxy.
An authenticated client is only a starting point for authorisation. The proxy should decide which destination names, ports and resolved address ranges that client is permitted to use. It should defend against address changes and rebinding according to its socket and policy design. A check on the initial string cannot substitute for an approved destination at actual connection time.
Private network risks are concrete. A UDP service bound to a loopback address may trust that incoming packets originate locally. If an open proxy sends traffic to that loopback service, the packets can appear to come from the proxy host and may bypass a source-IP-only restriction. RFC 9298 explicitly calls out localhost, link-local, multicast and broadcast destinations among classes needing careful prohibition.
A safe organisation starts with an allowlist or other restrictive destination policy, binds policy to the exact resolved IP and target port, and records the decision without logging secrets or arbitrary packet bodies. It should also decide what happens on DNS errors, multiple returned addresses and subsequent changes. Do not mask a denied private target as an intermittent packet-loss problem.
The proxy must verify UDP packets coming back
A UDP socket can receive packets without a TCP-style established peer relationship. RFC 9298 describes using connected UDP sockets when supported so the operating system can filter by the expected tuple. If the proxy uses an unconnected socket, it must validate the source IP address and UDP source port of received packets against the requested target. Unexpected packets must be discarded.
Otherwise an attacker able to send packets to the proxy’s UDP socket could inject bytes that are relayed to a client as if they came from the authorised target. That would compromise a critical association between the control-plane request and the received data plane. Matching only the remote hostname text is insufficient when the actual packet has a numeric source IP and port.
Consider a fictional approved tunnel to UDP target 192.0.2.20 port 4500. A packet arriving from 192.0.2.30 port 4500 is not automatically acceptable just because both addresses are examples from the same documentation range. Similarly, the correct IP with a different source port should not be accepted on a policy expecting the originally requested target tuple. These are illustrative validation cases, not live firewall instructions.
The proxy should also avoid forwarding client packets to unauthorised destinations if the underlying socket or routing state changes. A successful acceptance test must cover both directions: client-to-target policy enforcement and target-to-client source verification. One-sided security testing leaves an obvious gap.
A tunnel lives with the request stream, not forever
RFC 9298 ties a proxy UDP socket’s lifetime to the corresponding request stream. The proxy maintains the socket while the request is open and closes the stream when the socket becomes unusable. It may apply inactivity timeouts under specified guidance. A tunnel is not a permanent administrative grant that should survive every session, process restart or authentication change.
An edge controller should record which client identity opened the tunnel, which target it selected and which HTTP request stream owns it. When the stream ends, resource cleanup matters: close the UDP socket, drop buffered datagrams and release policy quotas. If a retry creates a new tunnel, the system must avoid assuming the old one was closed unless that state was verified.
One dangerous failure pattern is a leaked tunnel that outlives the authorisation decision. Suppose an operator removes access for an API agent but its datagram relay remains active because the HTTP stream was not actually terminated. An access-control database update alone would not remove the already-open socket. The proxy needs a revocation and lifecycle plan appropriate to its architecture.
Health checks should distinguish an HTTP stream that remains open, a UDP socket that exists and a remote UDP service that actually responds. These are three different observable states. A tunnel may be open but useless because the target is unreachable, filtering discards its packets or application-level authentication fails.
UDP delivery, unreliability and layered recovery
UDP transports messages independently and supplies no built-in end-to-end guarantee that every datagram will arrive. HTTP/3 QUIC DATAGRAM frames preserve an unreliable mode at the outer layer. That can be important when the inner application protocol, such as a QUIC-based service, already has its own recovery and congestion control. The proxy is a relay, not the authority that repairs arbitrary application messages.
If a CONNECT-UDP tunnel is instead carried over an HTTP/2 Capsule stream on TCP, outer delivery is reliable and ordered. A loss can induce TCP recovery before later bytes are delivered. The inner application may also try to recover losses. These nested mechanisms can create head-of-line delay or competing retransmission behaviours. RFC 9298 therefore recommends HTTP/3 for cases where its unreliable QUIC Datagram support is available.
Imagine a fictional sender transmits one thousand datagrams, each belonging to the same permitted tunnel, and a receiver records 997. The observed missing fraction is three divided by one thousand, equal to 0.3%. This does not identify the loss location or prove a particular HTTP version was at fault. Packets may be dropped by the sender, proxy, network path, receiving socket or application filtering.
To diagnose a loss problem, instrument counts at each relevant boundary without indiscriminate payload recording. Track datagrams accepted by the client transport, received by the proxy, forwarded on UDP and observed by the remote service. Add timestamps and known request identities. A single aggregate loss rate cannot distinguish transport loss from deliberate security drops or an application that was never listening.
MTU and framing budget: why bigger packets can disappear
An HTTP/3 Datagram must fit within constraints imposed by QUIC, the negotiated Datagram support and the path’s packet size. RFC 9298 explicitly prohibits the UDP proxy from introducing IP fragmentation when forwarding HTTP Datagrams. An oversized datagram may be discarded. Sending a larger application message does not guarantee that the underlying network will split it helpfully and reconstruct it later.
Use a stipulated budget to understand sizing. Suppose a test environment allows at most 1,250 bytes for a particular outer datagram, and all framing and transport overhead relevant to that budget consumes an illustrative fifty bytes. The largest user payload under this made-up arrangement is 1,250 minus 50, or 1,200 bytes. That is a capacity example with explicit units, not a universal MASQUE header length.
If the application attempts 1,240 user bytes under that same stipulated budget, the total becomes 1,290 bytes and exceeds the limit by forty bytes. The sender should not assume that the proxy will use IP fragmentation to rescue it. Correct production sizing requires the actual transport overhead, Context ID encoding length, QUIC configuration, current path and downstream UDP constraints.
Where a proxied UDP payload cannot fit in the appropriate outbound QUIC Datagram, the RFC provides guidance on dropping it and communicating an ICMP Packet Too Big indication when possible. Application developers should investigate packetisation-layer path-MTU discovery rather than blindly retrying the same oversized payload indefinitely.
Worked capacity calculation with honest units
Consider a fictional proxy policy allowing one authorised client at most 120 forwarded UDP datagrams per second in one direction. If the average forwarded UDP data payload during a measurement interval is 600 bytes per datagram, the allowed payload rate is 120 multiplied by 600, equal to 72,000 bytes per second. Multiplying by eight gives 576,000 bits per second, or 0.576 megabits per second in decimal units.
That figure describes only payload in the specified direction under the stipulated average. It excludes IP, UDP, QUIC, HTTP Datagram and other transport overhead, as well as retransmission, reverse traffic and control messages. If the same byte-rate reasoning is applied to eight independently limited clients each reaching its maximum, aggregate one-direction payload is 576,000 bytes per second, or 4.608 megabits per second.
Do not automatically double the result for return traffic. Responses may be smaller, larger, absent or limited under different policies. A proxy carrying potentially amplifying UDP protocols needs explicit outbound and inbound quotas and destination restrictions. RFC 9298 warns that UDP forwarding can continue without a target’s TCP-style consent, making abuse controls especially important.
Capacity policy is an operational safeguard rather than an advertised RFC-wide number. Choose thresholds according to the actual service, infrastructure and abuse analysis. A test report should state the numerator, denominator, interval and direction, for example 120 datagrams per second per authorised tunnel. The phrase rate limit enabled is too vague to establish that packets or bytes were controlled.
Why an unrestricted UDP proxy can become an attack tool
A UDP proxy sends packets with a source address associated with the proxy, not the original HTTP client. If an adversary can select arbitrary targets, they can direct traffic through the proxy toward systems that may trust or block the proxy differently. That source substitution can bypass crude IP-based controls or hide the attacker’s own network identity from the target.
UDP also lacks an initial handshake in which the target demonstrates willingness to receive traffic. A compromised client can ask an open proxy to send large volumes toward an unresponsive destination. Unlike a TCP CONNECT case where connection establishment may fail or stall, a UDP proxy could continue transmitting. Access control and rate limits belong at the proxy regardless of application-layer authentication.
The safe design starts by rejecting unauthorised destinations rather than trying to detect malicious bytes inside every datagram. Authenticate the requester, restrict allowed target hosts and ports, block vulnerable address ranges, cap concurrency and throughput, and ensure the proxy cannot reach administrative services it should never expose. Audit attempted policy violations without leaking personal payloads.
No single control is complete. A destination allowlist may contain a service that later becomes unsafe; quotas may be insufficient against many identities; an application may amplify responses unexpectedly. Use layered safeguards and operational monitoring. Publishing a generic how-to for creating a public unrestricted proxy would be irresponsible; the reader job here is understanding and enforcing the permitted tunnel boundary.
The March 2026 HTTP/1.x optimistic-send prohibition
The original RFC 9298 described the possibility of a client beginning to send UDP packets before the proxy had replied, known as optimistic sending. That can save a round trip on compatible transports, but it creates a special danger when an HTTP/1.1 Upgrade is not accepted and the following bytes are interpreted as ordinary HTTP/1.1 requests instead of tunnel data.
RFC 9931, published March 2026, updates the standard. Optimistic UDP packet sending is permitted only when the HTTP version is HTTP/2 or later. Clients must not send UDP packets optimistically over HTTP/1.x. The change addresses request-smuggling and parser boundary risks. A 2026 implementation guide that repeats the older permission without this restriction would be materially incomplete.
Even with HTTP/2 or HTTP/3, optimistic datagrams are not guaranteed to be processed. The proxy may reject the request or receive a datagram before the control-plane request is available and choose to drop it. Applications must tolerate that possibility rather than assume the first optimistic packet reached the remote target. Reduced setup latency is not proof of successful delivery.
A regression test should cover HTTP/1.1 Upgrade rejected, HTTP/1.1 Upgrade accepted, HTTP/2 extended CONNECT rejected and HTTP/3 extended CONNECT accepted. The HTTP/1.1 cases must demonstrate no premature UDP payload bytes before confirmation. The goal is protocol compliance and parser safety, not a superficial benchmark that counts only the fastest happy-path handshake.
Distinguish a rejected request from missing target replies
HTTP failure responses can explain why tunnel establishment was refused. RFC 9298 recommends use of suitable Proxy-Status details when DNS resolution or destination policy blocks the request. Such diagnostics are valuable because a client can then distinguish no tunnel from an established tunnel whose UDP target does not respond. The two states require very different repairs.
Suppose the proxy rejects telemetry.example.test because its DNS lookup fails. That is a control-plane failure, not an observed UDP packet loss. Suppose resolution succeeds and the HTTP tunnel is accepted, but no UDP response returns. The target may be absent, a firewall may block the path, the data may not be valid for the application or packets may be lost. Without additional instrumentation the proxy cannot reliably identify one cause.
A robust client avoids infinite retry storms. When establishment fails, apply a bounded retry policy appropriate to the error, respect authentication or policy denials and avoid retrying permanent invalid destinations. When datagrams are dropped after acceptance, investigate packet size, path loss, source verification and target service behaviour without creating duplicate tunnels blindly.
An incident report should separate establishment attempts, successful proxy requests, outbound UDP datagrams, inbound UDP datagrams, policy denials and network errors. One total failure counter hides whether the problem is authorisation, DNS, negotiation, MTU, remote reachability or application semantics.
Unknown contexts and streams require bounded buffering
Datagrams may arrive before their associated HTTP request or before a Context ID is known. The standards permit specified handling that can include dropping the datagram or buffering it briefly while waiting for necessary control-plane state. Unbounded queues would expose memory and latency to a sender who generates arbitrary identifiers. Bounded buffering is part of safe protocol implementation.
Define independent limits by stream, context, connection and authenticated principal where appropriate. A client should not be able to create thousands of half-known contexts and consume a disproportionate share of the proxy’s memory. If a buffer budget is exhausted, dropping an unprocessed datagram is safer than allowing resource starvation that affects other users.
Use a fictional example: a connection-level buffer permits at most thirty datagrams, averaging 800 bytes each. The nominal payload storage budget is 24,000 bytes, excluding metadata and allocator overhead. A request that would place the thirty-first pending datagram in that queue needs a documented drop or rejection rule. The figure is not an RFC-imposed quota; it illustrates how an engineer states a measurable resource boundary.
Monitor buffer occupancy, reasons for drops and ages of queued datagrams. A high rate of unknown-stream arrivals may indicate reordering, a client bug or abuse. Treat those explanations as hypotheses to test with traces. Avoid logging full user datagram payloads merely to identify context errors; identifiers and bounded metadata are often sufficient.
How this transport fits into a real AI-agent service
An AI agent may call external APIs or internal tools that rely on ordinary networking, sometimes including QUIC or other UDP-based paths. CONNECT-UDP can be a transport option when there is an authorised proxy infrastructure between the agent’s execution environment and a permitted target. It does not make the model more intelligent or approve the agent’s requested tool action.
Separate the authority chain. The application decides whether the agent may use a tool. The identity system authenticates the calling service. The proxy checks whether that principal may establish a UDP tunnel to this particular destination. The target’s application then validates any required end-to-end protocol identity or token. A successful step does not automatically authorise every later step.
Imagine a fictional analysis worker requesting a UDP tunnel to an approved service and then trying the same mechanism against the proxy’s own loopback diagnostics port. The first may be permitted; the second should be rejected under a restrictive policy even when both requests carry valid client authentication. The agent’s intention or fluent explanation cannot override network authorisation.
Practical supervision includes approval of destination classes, quotas, expiry and revocation of credentials, monitoring for unexpected tunnels and humane escalation for risky changes. The article’s series title uses Superintelligence, but the mechanism is existing MASQUE and HTTP security engineering for present-day systems. No artificial superintelligence is asserted to exist.
How this differs from Alt-Svc and other HTTP mechanisms
HTTP Alt-Svc lets an origin advertise alternative transport endpoints while preserving authority for the original resource. It is a protocol-discovery and routing feature. CONNECT-UDP instead authorises a client-specific tunnel through a proxy to a UDP target. Both may involve HTTP/3, but an Alt-Svc advertisement is not permission to use an arbitrary UDP relay.
The site’s existing Agent HTTP Alt-Svc guide owns alternative endpoint advertisements, origin checks and migration. Its correctness conditions should not be transposed into a CONNECT-UDP design. A proxy must enforce its own target rules even when the HTTP connection reached it through a valid alternative service.
A WebSocket handshake establishes a full-duplex application channel with specific Origin and subprotocol checks; it is not a protocol for forwarding independent UDP datagrams to arbitrary target hosts. Read the verified Agent WebSocket Handshakes guide for that separate mechanism. The fact that HTTP/1.1 can upgrade protocols does not make their security rules interchangeable.
Ordinary URL fetching introduces additional SSRF and redirect risks when an agent retrieves resources. The existing Agent Safe URL Fetching guide addresses destination validation in that HTTP request context. CONNECT-UDP shares the principle of restricting targets but operates with a different datagram data plane and request lifetime.
Measure the correct outcomes with clear denominators
Proxy success is not a single metric. Define tunnel establishment success as accepted, authorised requests divided by eligible establishment attempts. Define datagram forwarding success at each direction and boundary using transmitted or received datagrams as the denominator. Define blocked-target effectiveness by testing explicitly forbidden addresses and recording rejections, not by assuming a low abuse rate proves the policy works.
Suppose a test includes 200 eligible authorised tunnel requests and 190 succeed, while ten fail due to DNS resolution. Establishment success is 190 divided by 200, or 95%. If accepted tunnels then send 50,000 datagrams and 49,500 reach a monitored target, observed delivery at that boundary is 99%. Neither number is a substitute for the other, and neither proves the proxy rejects forbidden destinations.
Add a separate security test pool of twenty deliberately forbidden targets, all of which should be rejected. If one prohibited target is accepted, the security failure is meaningful regardless of the overall 95% establishment score. This example is a proposed test design, not evidence that any real proxy achieved those results.
A serious report also measures p95 setup latency, memory per tunnel, buffers, expiry cleanup, rate-control enforcement, packet-size drops, HTTP version negotiation and any exposure of private address space. Use versioned source code and synthetic test endpoints. The denominator for a policy claim must correspond to the population it was supposed to protect.
Independent changed-context exercise and worked answer
Consider a fictional proxy behind HTTP/3. An authenticated client requests a UDP tunnel to 192.0.2.50 port 443, which is on its approved target list. The HTTP request uses client-initiated bidirectional stream ID 24 and the Datagram Context ID zero. The network’s stipulated outer payload budget for this exercise is 1,300 bytes, with forty bytes of all relevant illustrative framing overhead. The client wants to send a 1,250-byte UDP data payload.
The Quarter Stream ID is 24 divided by four, equal to six. Context ID zero identifies the ordinary UDP data payload for the accepted tunnel. Under the invented budget, maximum data bytes are 1,300 minus forty, equal to 1,260, so 1,250 fits with ten bytes to spare. This does not mean every real QUIC path has that overhead or that the target application will respond.
Change the target to 127.0.0.1 while leaving the client authenticated, packet size and stream fields identical. A safe restrictive proxy refuses the destination because it is loopback, regardless of successful identity checks. Change the HTTP transport instead to HTTP/1.1 and have the client send UDP payload bytes before upgrade acceptance: under the March 2026 RFC 9931 rule this optimistic sending is forbidden. The mathematics remains true while security and transport conclusions change.
Finally change the payload to 1,290 bytes without changing the invented 1,260-byte data allowance. It now exceeds the budget by thirty bytes and must not be assumed to fit through IP fragmentation introduced by the proxy. This four-part transfer exercise tests the separation of framing, authorisation, current protocol rules and MTU, rather than memorisation of a single RFC number.
Limits, evidence and what to verify before deployment
CONNECT-UDP is an established protocol building block, not a turnkey secure VPN or universal proxy. Security depends on authentication, destination policy, address filtering, datagram limits, protocol versions, source verification and lifecycle cleanup. Implementations may support different HTTP versions and negotiated Datagram options. Verify actual software behaviour rather than infer compatibility from a package name.
The performance of a tunnel depends on the outer HTTP transport, network path, inner application protocol, congestion control and packet sizes. Encapsulation adds overhead and different transport choices can alter head-of-line blocking or delivery. No generic claim that this is always faster than direct UDP can be made without comparing the same application under controlled conditions.
Current standards matter. The 2026 RFC 9931 update to optimistic HTTP/1.x transitions must be applied when interpreting the earlier 2022 RFC 9298. Do not copy an older example that sends early UDP payloads over an HTTP/1.1 Upgrade. Likewise, CONNECT-IP’s later update addresses a different IP-tunnel scope and should not be mistaken for authorisation to forward arbitrary IP traffic under the CONNECT-UDP contract.
The transferable engineering principle is simple: a tunnel’s data plane must remain tied to the exact request, target and security policy that created it. If identifiers, sockets, address resolution, timing or request state change, validation must change accordingly. A correct relay is one that rejects forbidden paths reliably as well as carrying permitted datagrams.
Frequently asked questions
Is CONNECT-UDP just an HTTP CONNECT request?
No. It is a specific HTTP extension for relaying UDP payloads to a target host and port. HTTP CONNECT traditionally establishes a TCP tunnel; CONNECT-UDP has version-specific extended CONNECT or Upgrade handling and uses HTTP Datagrams and the Capsule Protocol.
Does a successful tunnel response prove the UDP target is online?
No. The proxy can open a UDP socket without a remote handshake. Success means the proxy accepted the tunnel and is willing to relay; the target may be unreachable or may never answer. DNS names must be resolved before the proxy’s successful response under RFC 9298.
What are the Quarter Stream ID and Context ID?
The Quarter Stream ID associates an HTTP/3 Datagram with an HTTP request stream; it is the client-initiated bidirectional stream ID divided by four. The CONNECT-UDP Context ID identifies the payload context, with zero used for ordinary UDP data on that tunnel.
Can an authenticated AI agent tunnel packets to a localhost service?
Authentication is necessary but not sufficient. RFC 9298 highlights localhost and other vulnerable address ranges as dangerous destinations. A proxy should deny targets outside the authenticated principal’s explicit network policy, because traffic would appear to come from the proxy itself.
Can the client send UDP packets before CONNECT-UDP is accepted?
On HTTP/2 or later, the protocol allows certain optimistic datagrams, which may still be dropped. RFC 9931, published March 2026, forbids optimistic UDP packet sending over HTTP/1.x due to request-smuggling risks.
Why not always use HTTP/2 Capsule delivery?
Capsules can carry datagram semantics over reliable HTTP streams, but an inner UDP-based loss-recovery protocol may then be layered over TCP recovery, adding delay or head-of-line effects. HTTP/3 QUIC DATAGRAM support can preserve unreliable delivery when available.
What happens if a datagram is too large?
Actual limits depend on negotiated QUIC Datagram size, framing and path MTU. RFC 9298 disallows the proxy from introducing IP fragmentation for forwarded HTTP Datagrams. Oversized datagrams can be dropped, so application packetisation and PMTU handling matter.
How do I know whether a packet drop was a security refusal?
Instrument and separate control-plane rejection, forbidden destinations, invalid source packets, buffer limits, oversize drops and downstream network loss. A final client timeout does not distinguish these cases. Review safe error and Proxy-Status data before retrying.
Does CONNECT-UDP grant application permissions to an agent?
No. It creates a transport forwarding path under a proxy policy. The target application still authenticates and authorises its own requests or protocols, and agent tool use still needs scope control and oversight. The protocol is not evidence that artificial superintelligence exists.
Which specification should I read first in 2026?
Start with RFC 9298 for CONNECT-UDP itself, RFC 9297 for HTTP Datagrams and Capsules, and RFC 9931 for the March 2026 HTTP/1.x optimistic-transition restriction. RFC 9484 covers the distinct CONNECT-IP protocol and an update to the well-known MASQUE registration.
Original standards and exact current updates
The primary specification is IETF RFC 9298, Proxying UDP in HTTP, published August 2022. It defines connect-udp request handling, URI Template variables, DNS requirements, socket and stream lifetime, UDP Datagram contexts, MTU restrictions and abuse hazards. Apply its updated requirements below rather than treating the original text as immutable.
The framing standard is IETF RFC 9297, HTTP Datagrams and the Capsule Protocol, published August 2022. It establishes request associations, Quarter Stream IDs and transport-specific Datagram behaviour. IETF RFC 9221, QUIC DATAGRAM explains the underlying QUIC Datagram extension.
The material 2026 correction is IETF RFC 9931, Security Considerations for Optimistic Protocol Transitions in HTTP/1.1, published March 2026, which updates RFC 9298 and prohibits optimistic UDP payload sending during HTTP/1.x upgrades. It explicitly retains the allowance only for HTTP/2 and later, where processing still is not guaranteed before acceptance.
For scope comparison, see IETF RFC 9484, Proxying IP in HTTP, published October 2023. It defines the separate CONNECT-IP mechanism and updates the MASQUE well-known URI registration. The toy packet counts, throughput, quotas and buffer budgets in this guide are independently constructed explanations, not benchmark results from any RFC.
Verified eduKate reading routes
Return to How Super Intelligence Works for the broader role of real models, tools, networking and human control. For the alternative routing of an HTTP origin to another transport endpoint, use Agent HTTP Alt-Svc. Its discovery rules do not authorise UDP target proxying.
For a distinct full-duplex HTTP Upgrade security problem, read Agent WebSocket Handshakes. For agent-side URL destination restrictions and rebinding threats on ordinary HTTP fetching, read Agent Safe URL Fetching. Those related owners explain different reader jobs.
The next independent check is to distinguish three statements: an HTTP tunnel has been authorised, a UDP packet has left the proxy, and the intended remote application has processed that packet. Only the first is established by a successful CONNECT-UDP response. Trace how the other two require distinct evidence and how the conclusion changes for HTTP/1.1 under RFC 9931.