UDP over SOCKS5: Private QUIC and WebRTC Routing

A browser does not send every request through one transport, so a SOCKS5 approval written for page loads says nothing about the datagrams a media call or an HTTP/3 connection will attempt later in the same session. In a controlled BotBrowser context the TCP and UDP decisions are selected separately, and neither one can turn a TCP-only relay into a UDP-capable service.

TL;DR

• The client opens two independent TCP control connections to the SOCKS5 proxy endpoint at :1080: one carries CONNECT for DST.ADDR/DST.PORT, and the other carries UDP ASSOCIATE; the relay can accept one and refuse the other.
• QUIC carries HTTP/3 over udp:443 and ICE gathers on udp:3478, so blocking UDP and opting out of QUIC are different controls.
• On ENT Tier3 --bot-udp-proxy sets the UDP and HTTP/3 decision per context, while --disable-quic still applies to the whole process.
• Qualification evidence has to come from a datagram test (tcpdump -n udp port 443), not from a curl --socks5-hostname download.

Contents

• Start With One Network Plan
• Make Separate Transport Decisions
• Set the Policy Per Context
• Protect Real-Time Media
• Validate Authorized Applications
• BotBrowser Support for UDP Proxy Policy
• Practical conclusion

Start With One Network Plan

A browser session can use more than one transport. Ordinary web requests commonly follow TCP, while HTTP/3 and parts of real-time communication can use UDP. A proxy approval that covers only web navigation therefore does not automatically cover every connection made by an authorized application. The deployment record needs to say which transports are permitted, which proxy service handles them, and what the browser should do when a permitted route is unavailable. In a controlled deployment BotBrowser can apply the selected TCP and UDP browser policy; it cannot turn a TCP-only proxy service into a UDP-capable one.

The useful question is not whether a proxy address appears in a launch configuration. The useful question is whether the complete application journey follows the network policy selected by the organization. Login, navigation, media setup, file transfer, background activity, and shutdown can exercise different browser features. A release review should consider the journey as a whole instead of treating one successful page load as proof for every path.

BotBrowser supports privacy-oriented routing policies for deployments that use SOCKS5 services with compatible UDP relay capability. TCP and supported UDP traffic can remain under one approved network plan when the service, browser policy, and application requirements agree. The service capability must be confirmed before release because SOCKS5 availability alone does not establish that UDP is included. A different mechanism for carrying UDP through a proxy is described in MASQUE and CONNECT-UDP for Web Operators.

Keep the plan easy to audit. Record the expected TCP route, the expected UDP route, the WebRTC policy, the HTTP/3 decision, the DNS policy, and the approved fallback. Assign an owner for each item. The record is complete when it names the proxy endpoint socks5://host:1080, the profile family, the UDP policy, and the expected result for each authorized feature.

Avoid treating UDP as an optional footnote. If an application does not need it, state the restriction. If it does need it, approve a compatible route and test the application through that route. A deliberate restriction is safer than an unreviewed direct path, and an explicit relay policy is safer than assuming that all traffic follows the same transport.

Make Separate Transport Decisions

TCP and UDP need separate decisions even when they share the same proxy vendor. They have different availability, fallback behavior, and application impact. A policy can allow both, allow TCP while restricting UDP, or allow selected UDP-dependent application features after review. The choice should follow business requirements and privacy controls rather than a generic browser default.

QUIC is associated with HTTP/3 and uses UDP. When an approved UDP route is available, an authorized application may use HTTP/3 under that route. When the deployment chooses a TCP-only policy, web navigation can use an approved TCP transport instead. This makes HTTP transport a deployment choice that can be documented and revisited during browser or infrastructure upgrades. --disable-quic changes QUIC and HTTP/3 only; it is not a switch for all UDP traffic, so WebRTC and STUN still require their own policy. For how authenticated QUIC routes and HTTP/3 limits are handled in practice, see QUIC Proxy Routing for HTTPS and HTTP/3, which covers transport choices, validation of limits and failures, and rollout records.

The protocol difference appears in the handshake. RFC 1928 gives SOCKS5 a datagram mode that a client must request explicitly before any packet leaves the relay. For a stream relay, the client opens a TCP control connection to the SOCKS5 proxy endpoint at :1080 and sends CONNECT naming DST.ADDR and DST.PORT. A UDP association uses a separate TCP control connection to the same proxy endpoint, carrying UDP ASSOCIATE. Each control connection carries one SOCKS5 operation; once CONNECT is accepted, that connection becomes a stream relay and cannot also carry UDP ASSOCIATE. The proxy can accept CONNECT on one connection while refusing UDP ASSOCIATE on the other, so a successful stream check does not establish UDP support. QUIC carries HTTP/3 over UDP :443, and STUN for ICE uses UDP :3478, so blocking UDP :443 removes HTTP/3 without touching WebRTC, which negotiates a=candidate pairs on its own path.

WebRTC requires its own decision. Real-time audio, video, and peer communication may depend on network discovery and media connectivity that differ from ordinary page requests. A TCP web proxy does not by itself prove that those activities follow the same privacy boundary. The release owner should decide whether real-time communication is allowed, limited, or unavailable for the workload. For the policy choices behind that decision, see WebRTC Network Identity and Privacy: Choosing the Right Policy, which compares the profile, real, and disabled postures and explains why candidate and statistics addresses should agree.

DNS belongs in the same review. A deployment can have an approved web route and still create inconsistent privacy behavior if name resolution follows another unreviewed path. The routing record should describe DNS ownership without assuming that a UDP relay automatically settles it. This keeps transport, name resolution, and real-time communication as related but independently reviewed controls. For a wider view of how these layers fit together, see Proxy, DNS, and WebRTC Consistency for a Coherent Browser Identity, which walks through a review sequence and common signs of a mismatch.

Do not use a single success result to infer the rest. A page that opens over an approved TCP route says little about media setup. A working video call says little about the DNS policy for later navigation. Each approved behavior needs evidence tied to the application journey and the selected deployment policy.

Set the Policy Per Context

One transport answer for the whole session is often too coarse. A single deployment can run one workload that needs an approved HTTP/3 route and another that should stay on TCP, and both may belong to the same profile family. Forcing one decision on both leaves the team choosing between an unnecessary route and an unnecessary restriction.

The current release makes that decision context-level. For ENT Tier3 deployments, --bot-udp-proxy sets whether a context uses UDP proxying and HTTP/3. A value on the main command line becomes the process default, and Per-Context Fingerprint can override it for a single context. A context without its own value follows the default, and the policy can be changed after the context is created. The process-level --disable-quic switch still takes priority for QUIC and HTTP/3, so a context override cannot re-enable them.

Two properties keep this reviewable. The policy stays scoped to the context that sets it, so a restriction placed on one workload does not remove HTTP/3 from the others in the same session. It also applies only to a valid loaded profile that already carries the UDP entitlement, so it selects between approved behaviors instead of granting a route that the deployment has not qualified. The flag does not purchase, add, or change that entitlement.

Record the choice per context, not per deployment. Each context should carry a named owner, the approved transport list, and the expected outcome when the relay is unavailable. That record is what lets a reviewer confirm months later why one workload used HTTP/3 and a neighboring workload did not.

Protect Real-Time Media

Real-time media deserves special attention because users can grant microphone or camera access while assuming that the surrounding network policy remains intact. The privacy review should begin before permission is granted. Determine whether the application genuinely requires real-time communication, which user roles may use it, and which network outcome is acceptable for those sessions.

A RTCPeerConnection gathers candidates until iceGatheringState reports complete, and every a=candidate line carries a type: host, srflx, or relay. Gathering that stops at srflx without a relay candidate points at the TURN server or the UDP :3478 path, not at the media codec.

For approved use, combine browser policy with a proxy service that supports the required traffic. The provider should be able to describe its UDP offering, geographic coverage, authentication model, service limits, and operational support in terms suitable for a customer review. The organization can then decide whether that service fits its data handling and access-control requirements.

Application testing should focus on expected user behavior. Confirm that authorized calls can start, remain usable, reconnect after ordinary network changes, and end cleanly. Confirm that permission prompts, mute controls, device selection, and session termination continue to behave as the product team expects. These checks protect privacy and reliability throughout the approved journey.

If real-time communication is not required, use a policy that prevents an unnecessary path from becoming part of the workload. The product owner should document the resulting user experience so that an intentional restriction is not mistaken for a service outage. Support teams also need a short explanation they can use when a page offers a media feature that the deployment does not approve.

Changes to media vendors, conferencing components, or embedded communication tools require renewed review. They may introduce new connection requirements even when the visible workflow looks familiar. Treat those changes like network changes, not ordinary text updates. Re-run the authorized journey and attach the result to the release record.

Qualify the Proxy Service

Proxy qualification is a procurement and operations task, not just a browser setting. Ask the provider whether the purchased service includes UDP relay capability for the regions, authentication method, and account tier that the deployment will use. Product names can be ambiguous, and capability may differ across endpoints or plans. Written confirmation reduces uncertainty during release review.

Ask for a test that exercises udp_associate rather than a TCP download. curl --socks5-hostname proxy.example:1080 https://example.com reaches the origin over TCP and proves nothing about datagrams, because curl cannot request the datagram mode. A capture with tcpdump -n udp port 443 on the approved path, or a QUIC request that completes while TCP :443 is blocked, shows that the service really forwarded datagrams.

Review how the provider communicates maintenance and service degradation. A team needs to know whether UDP availability is reported separately from TCP availability, how endpoint changes are announced, and what support information is available during an incident. A general statement that the proxy is online may not explain whether a real-time application can use its approved route.

Check commercial and governance requirements as well. Data processing terms, retention practices, access controls, credential rotation, regional routing, and incident response all affect whether the service belongs in a privacy-sensitive deployment. UDP support is useful only when the rest of the service meets the same organizational standard as the TCP route.

Keep provider credentials outside page content and source-controlled examples. Limit access to the systems and operators that need them. Rotate them according to the same policy used for other network secrets, and ensure that a replacement credential can be introduced without changing the approved route design.

Qualification should produce a concise service record: approved provider and plan, covered environments, responsible owner, expected transports, support contact, review date, and fallback decision. Link supporting provider material from the internal change record. That record is more durable than relying on a setup note or a remembered conversation.

Recheck qualification after contract, endpoint, region, or authentication changes. The browser configuration may remain visually similar while the purchased capability changes. A release should not inherit an old approval when the underlying service has materially changed.

Read the Command-Level Reply, Not the TCP Result

The test below compares two independent TCP control connections to the same proxy endpoint: a SOCKS5 CONNECT for a stream destination and a separate UDP ASSOCIATE. A single local relay accepts the first and refuses the second with an explicit reply rather than a timeout, isolating protocol support from the routing behaviour of a purchased service. Each connection repeats the same greeting and authentication exchange; the replies apply to their respective connections, not to two halves of one session.

Independent TCP control connection	Endpoint answer	What it establishes
A: CONNECT for DST.ADDR/DST.PORT	accepted	the stream path is approved
B: UDP ASSOCIATE to the same proxy endpoint	refused as unsupported	the association is not offered
Separate compatibility probe: older SOCKS protocol	connection reset	the relay answers the current protocol only

The practical consequence is that an accepted CONNECT says nothing about UDP ASSOCIATE at the same proxy endpoint. A page load through the stream relay can complete while the separate control connection for UDP association receives a refusal, and a reviewer who treats stream success as approval for HTTP/3 or real-time media records a qualification that was never performed. The answer also differs in kind: an unsupported operation is a capability gap, while an unreachable destination is a routing gap, and the two call for different follow-up from the provider.

The same transcript shows why a client cannot infer support in advance. Both independent connections use the same greeting and authentication, and the relay does not announce which operations it supports, so each reply must be recorded against its own connection and operation. A qualification record that stores endpoint, port, account and date but omits those replies is incomplete because it cannot show which request was approved.

This measurement was taken against a relay configured to decline datagram association, so it demonstrates the protocol distinction rather than the capability of any particular provider. Repeating the pair over two independent TCP control connections to a service that supports datagram association should yield acceptance for both operations; that comparison turns a provider claim into evidence.

Define Allowed Outcomes

Write acceptable outcomes before testing. For an application that requires HTTP/3, the approved outcome may be successful operation through the reviewed UDP-capable service. For an application that does not require it, the approved outcome may be continued web operation through TCP. For a WebRTC workload, the decision may allow real-time communication only in environments where the reviewed media route is available.

Make the outcome observable with tools the operator already has. chrome://net-export records a NetLog that shows whether a QUIC connection was attempted and where it failed, and a proxy that rejects the UDP path typically leaves a 502 on the TCP fallback. For media, pc.getStats() reports the selected candidate pair, so a relay-only outcome is checked rather than assumed.

Also write the unavailable outcome. If the relay service cannot support the approved UDP-dependent feature, decide whether the application should use an approved alternative transport, disable that feature, present a controlled error, or pause the workload. An unspecified fallback often becomes an accidental network path or an inconsistent user experience.

The outcome should be visible to operators. Health status, application logs, and provider status can indicate whether the selected policy is available. Operators need enough information to choose the approved response and follow the documented recovery path.

Separate privacy acceptance from performance preference. A faster transport is not automatically acceptable, and a slower approved fallback is not automatically a failure. Measure user impact after confirming that the route remains within policy. This ordering prevents performance tuning from weakening a privacy decision.

Apply the same outcome language to development, staging, and production where practical. If a lower environment uses a different proxy capability, mark that difference in test results. Otherwise a successful staging result can create false confidence about production behavior.

Finally, identify who can approve exceptions. Temporary service conditions may require a restricted mode, but an operator should not invent a new route during an incident. A documented approval path keeps urgent decisions accountable and makes later review possible.

Validate Authorized Applications

Validation should use applications and accounts that the organization is permitted to test. Select journeys that represent normal user activity, including initial navigation, authenticated work, background requests, real-time media when approved, and orderly sign-out. The test should confirm product behavior and policy compliance together.

Begin with a clean environment that uses the intended browser release, profile family, proxy service, and network policy. Record those inputs in the test case. Consistent inputs make later comparisons useful when a browser, profile, application, or provider version changes.

Observe user-visible results and approved operational telemetry. Pages should load as expected, protected actions should complete, media should follow its approved availability decision, and restricted features should fail in the planned way. Provider-side service status and organization-owned network records can support the result when they are available under the organization’s privacy policy.

Prefer browser instrumentation to impressions. chrome://webrtc-internals shows which ICE candidate pairs a call actually used, and chrome://net-export records the QUIC attempts made by page loads. On the network side, tcpdump -n udp port 443 separates forwarded QUIC from a silent direct path. Store the tool, its output file, and the capture window next to the result.

Include interruption cases that reflect ordinary operations. A credential rotation, endpoint maintenance event, browser restart, or short network interruption should lead to the documented fallback or recovery behavior. Confirm that the application does not silently continue in a mode that the release owner did not approve.

Repeat the journey after meaningful changes. Browser-family updates, proxy plan changes, WebRTC component changes, DNS policy changes, and application network changes can all affect the result. A previous pass remains historical evidence, not permanent approval.

Keep the test narrow enough to interpret. If many infrastructure changes are combined, a failed result becomes difficult to assign and a successful result proves little about any individual change. Stage changes where possible and preserve the last accepted configuration so the team can compare and recover.

Handle an Unavailable Relay

An unavailable UDP relay is an expected operating condition that needs a planned response. The correct response depends on the application. QUIC and HTTP/3 should fall back to approved TCP navigation when that path is available, while UDP-dependent real-time features should remain unavailable or use another already-approved route. The policy should prefer a clear restriction over an unapproved direct connection and must not silently send UDP directly.

Protocol signals make the response testable. RFC 1928 returns explicit reply codes: 0x07 means the method is not supported and 0x03 means the network is unreachable. A client that receives 0x07 for udp_associate should record UDP as unqualified instead of retrying directly. chrome://net-export then shows the QUIC attempt falling back to TCP, and the absence of a relay candidate explains a call that no longer connects.

Define the response at deployment design time. State which workloads can continue, which must stop, what users will see, and who receives an alert. If the organization uses more than one approved provider or endpoint, document the conditions for switching and ensure that the alternative has completed the same qualification process.

Avoid automatic changes that broaden access without review. A fallback should not exchange a restricted network policy for general host connectivity merely to keep a feature working. Continuity matters, but it must remain inside the approved privacy boundary.

Recovery needs its own check. When service returns, confirm that the application resumes the intended route and that temporary restrictions are removed in a controlled manner. Do not assume that a browser process started during the incident adopts the restored policy without the normal lifecycle steps defined by the deployment.

Communicate the distinction between a service fallback and a product defect. If HTTP/3 is unavailable but approved web navigation continues over TCP, that can be an accepted transport change. If an approved call cannot start because the required route is unavailable, that can be an intentional privacy protection. Clear support language reduces pressure to weaken the policy during an incident.

After recovery, add the incident outcome to the service record. Note the affected application behavior, the approved response, the recovery action, and any follow-up assigned to the provider or internal owner. This turns an outage into evidence for the next review.

Keep Release Evidence

A release decision should be reproducible from its evidence. Store the browser release, profile family, application version, proxy service, selected regions, network policy, test date, owner, and outcome. Include the fallback that was exercised or confirmed. These details allow a later reviewer to understand what was actually approved.

Attach artefact names, not screenshots alone. A chrome://net-export NetLog, a tcpdump -n udp port 443 capture limited to the test window, and a pc.getStats() dump for a single call stay small enough to store, and each carries timestamps that tie it to the release. Record the browser build that produced them, because NetLog event names and the QUIC version negotiated under RFC 9000 change between releases.

Prefer concise records over large raw captures. A signed test result, change ticket, provider capability statement, and selected operational logs usually provide a clearer audit trail than an unrestricted collection of network data. Follow organizational retention and access rules because network records can contain sensitive information.

Connect evidence to a specific release. A provider statement can support qualification, but it does not prove that a particular application journey passed. An application result can prove user behavior, but it does not replace provider governance review. Keep both under the same release decision with their roles clearly identified.

Record negative and restricted outcomes. If a feature is intentionally unavailable under a TCP-only policy, a passing test should say so. This prevents a later team from interpreting absence as missing coverage and enabling a route without approval.

Use comparable names across environments. The same policy label should mean the same transport decision in staging and production. Where environments differ, state the difference beside the result. Consistent naming makes audits faster and reduces deployment mistakes.

Evidence expires when material assumptions change. Set a review trigger for browser updates, proxy service changes, application network changes, regional changes, and security-policy revisions. The trigger is more useful than an arbitrary promise that one successful test will remain valid indefinitely.

Operate Within Clear Boundaries

Ownership keeps network privacy controls reliable. The application team knows which features need real-time communication. The platform team owns browser and proxy configuration. Security or privacy reviewers define acceptable routes. Operations responds to service changes. Support explains intentional restrictions to users. Put those responsibilities in the deployment record.

Use change control for proxy endpoints, provider plans, WebRTC policy, HTTP/3 policy, DNS policy, and browser release updates. A small configuration edit can change the effective network plan. Peer review and staged rollout reduce accidental policy drift.

Monitor the outcomes that operators can act on: service availability, application success, approved fallback use, authentication health, and provider notices. Avoid collecting more user or network data than the operating decision requires. Privacy controls should not create a new source of unnecessary telemetry.

Keep production credentials and evidence access limited. Test accounts should have only the permissions needed for the authorized journey. Release records should be available to reviewers and responders, not broadly exposed. Apply retention rules consistently after an investigation or rollout completes.

Document the boundary of support. A compatible relay depends on the provider, region, account, and application requirements. BotBrowser can apply the selected browser policy, but it cannot turn a TCP-only service into a UDP-capable one. This distinction helps teams send service questions to the right owner.

Train incident responders on the approved fallback. They should know when TCP continuation is allowed, when real-time features must remain restricted, and who can authorize an alternative. A short runbook is more useful during an outage than a long protocol description.

Review Before Every Material Change

Review the network plan before the first production launch and after each material change. Confirm that the application still needs the approved UDP-dependent features. Confirm that the proxy service and purchased plan still provide the required capability. Confirm that TCP, UDP, WebRTC, HTTP/3, and DNS decisions remain recorded as separate controls.

Run the authorized application journey using the intended environment. Compare the result with the allowed outcomes. Exercise the documented fallback without introducing a new route. Save the release evidence and obtain approval from the owners named in the deployment record.

Keep one repeatable check per transport. For QUIC, load a page over HTTP/3 and confirm the attempt in chrome://net-export; for media, place a call and read the selected pair from pc.getStats(); for the relay itself, run tcpdump -n udp port 443 on the host that carries the approved route.

During rollout, watch application health and provider status. Start with a controlled scope that allows recovery to the last accepted configuration. Expand only after the expected user behavior and privacy policy remain stable. If the result differs, pause the rollout and use the documented restriction or rollback.

The same review applies when a feature is removed. Update the policy so that an obsolete UDP path does not remain approved after the application stops needing it. Removing unused network access reduces operational complexity and narrows the privacy boundary.

BotBrowser Support for UDP Proxy Policy

For ENT Tier3 deployments, BotBrowser supports context-level UDP proxy policy decisions and can route QUIC plus WebRTC ICE/STUN-related UDP through SOCKS5 services that support UDP ASSOCIATE. This capability allows organizations to document and validate separate transport policies per workload, with fine-grained control over which contexts use HTTP/3 and which remain on TCP; it does not claim that every WebRTC media stream is routed through the proxy. However, BotBrowser cannot guarantee provider UDP relay availability or quality, control upstream SOCKS5-to-origin behavior, replace an unavailable relay with direct connections, or verify that a provider’s UDP service meets organizational privacy standards. The responsibility for qualifying the proxy service, confirming purchased capability in your regions and authentication method, and measuring compliance with your privacy requirements remains with your organization and the provider.

Practical conclusion

A sound release does not depend on assuming that every browser connection follows one path. It identifies the transports an application needs, assigns an approved route or restriction to each, validates normal user behavior, and preserves enough evidence for the next change. That process keeps performance, availability, and privacy decisions visible to the people responsible for them.

Public Sources

• https://botbrowser.io/docs/network/udp-over-socks5/
• https://www.rfc-editor.org/rfc/rfc1928
• https://developer.mozilla.org/en-US/docs/Glossary/QUIC
• https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API
• https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-stun-consent-freshness

For implementation details and supported deployment options, use the UDP over SOCKS5 documentation. Related guidance covers proxy, DNS, and WebRTC consistency and HTTP/3 compatibility. Product planning can also reference BotBrowser features, pricing, and downloads. Keep public guidance focused on policy and authorized validation; keep environment-specific credentials, provider records, and test evidence in the organization’s controlled systems.