Skip to main content
anyIP proxies support UDP (User Datagram Protocol) allowing for advanced use cases such as HTTP/3, QUIC, and next generation streaming protocols.
Beta FeatureUDP support is currently available to all users in beta. Please contact our support team if you have any questions or feedback.

​
🕵️‍♂️ Enhanced Stealth

Using UDP proxies significantly improves your stealth profile. Modern browsers and apps increasingly rely on UDP-based protocols (like QUIC/HTTP3).
  • Blend In: Most real residential traffic uses QUIC. If you force TCP-only (HTTP/1.1 or HTTP/2), your traffic pattern looks distinct from regular users.
  • Modern Footprint: Supporting UDP makes your bot or scraper indistinguishable from a standard Chrome or mobile user.

​
🚀 How UDP Support Works

UDP (user datagram protocol) is connectionless, unlike its connection oriented counterpart TCP. UDP headers are commonly used with speed-requirement intensive applications (VoIP, gaming, streaming).
  • Protocol: UDP is supported ONLY via SOCKS5.
  • Port: Same port as TCP (1080).
  • Authentication: Standard username/password authentication works for UDP.
Compatibility WarningNot all proxy clients or software support UDP over SOCKS5. Many standard HTTP libraries (like Python requests or standard curl) do not support UDP proxying.

​
🛠 How to Test UDP Compatibility

The quickest way to verify that your configuration is tunneling UDP traffic properly is to verify support for HTTP/3 (QUIC) which can only operate over UDP.

​
Step-by-Step Test

  1. Configure your browser or client to use our proxy via SOCKS5.
  2. Visit this test page: https://cloudflare-quic.com/
  3. Check the result:
    • Success: You see the message: “your browser used HTTP/3”.
    • Failure: You see: “your browser used HTTP/1.1” or “HTTP/2”.
Reload Required?Browsers often attempt TCP/HTTP2 first. If you don’t see HTTP/3 immediately, reload the page a few times to force the browser to switch to the QUIC protocol.

​
Why am I seeing HTTP/1.1 or HTTP/2?

HTTP 1.1 or HTTP/2 means your connection is falling back to TCP. This typically occurs because:
  • Your proxy client is configured for HTTP instead of SOCKS5.
  • Your software/browser does not support UDP Associate (the SOCKS5 command for UDP).
  • The target website has not advertised HTTP/3 support yet (unlikely for the test page).

​
WebRTC and UDP in anti-detect browsers

WebRTC is UDP-based. In order for WebRTC traffic to exit via your anyIP proxy, both of the following must be true:
  1. The proxy is configured as SOCKS5 in the browser profile.
  2. The anti-detect browser itself supports UDP over SOCKS5.
UDP is handled by anyIP on the proxy side. If the browser doesn’t send UDP traffic over the SOCKS5 proxy, WebRTC traffic never reaches anyIP and there’s no flag nor dashboard setting you can change to make it happen. That’s why same anyIP creds can pass WebRTC tests on one anti-detect browser and fail another.

​
Known browser behavior

For other browsers and tools, check the vendor documentation for UDP over SOCKS5 support before troubleshooting the proxy. Setup steps for each browser are in the Integration Guides.

​
Check that the profile uses SOCKS5

In the browser profile, confirm these values:
  • Proxy type: SOCKS5, not HTTP or HTTPS.
  • Host: portal.anyip.io
  • Port: 1080
  • Username: your full username string, for example user_XXXX,type_mobile,country_DE,session_test1
  • Password: your proxy password
Some browsers will not accept the socks5:// prefix in the proxy line. If your browser does not accept that line copy/paste, choose SOCKS5 in the proxy type selector and paste directly: portal.anyip.io:1080:user_XXXX,type_mobile,country_DE,session_test1:PASSWORD If there is a separate UDP option under the browser profile in proxy/profile settings, ensure it is turned on.

​
What a WebRTC IP test tells you

The WebRTC leak test IP address is what WebRTC reveals. Compare with the proxy IP displayed on an IP-check site from the same profile.
  • The WebRTC IP matches the proxy IP: WebRTC traffic is going through the anyIP proxy.
  • The WebRTC IP is different from the proxy IP, or shows your real IP: WebRTC traffic is not going through the proxy. The browser is not sending UDP over SOCKS5.
A WebRTC leak result does not mean the anyIP proxy has stopped working. Regular TCP traffic (normal page loads) can still use the proxy while WebRTC bypasses it. Browser WebRTC spoofing or substitution options also change what the test displays, so a spoofed result does not confirm that UDP is routed through the proxy. Use the HTTP/3 test in the same profile to confirm UDP routing directly.

​
When one browser fails and another works

When WebRTC or UDP doesn’t work with one anti-detect browser but does work with another using the same anyIP credentials. The issue is between the browsers not the proxy. Try this instead:
  1. Confirm the failing profile uses SOCKS5 and not HTTP.
  2. Check whether the browser supports UDP over SOCKS5. If it does not (for example, AdsPower), UDP and WebRTC traffic will not go through the proxy in that browser.
  3. Enable any UDP option in the browser’s proxy or profile settings.
  4. Run the HTTP/3 test at https://cloudflare-quic.com/ in the failing profile and reload a few times.
  5. If you need WebRTC or UDP through the proxy, move the profile to a browser that supports UDP over SOCKS5, such as OctoBrowser.

​
Proxy check fails with detailed location filters

If the browser’s proxy check fails or returns no IP when your username includes region_, city_, or asn_ flags, there may be no available peers matching those parameters at that moment. Remove non-essential filters to increase the available pool. For example, use user_XXXX,type_mobile,country_DE,session_test1 instead of a username that also targets a specific region and city. See Location Targeting for the available flags.