UDP over SOCKS5: six tests, one profile, one IP address
Sophia Grote
Support specialist, Octo Browser
Octo Browser supports UDP over SOCKS5, which means WebRTC, QUIC, HTTP/3, and WebTransport go through the proxy rather than bypassing it. We wanted to see whether that is actually the case.
It’s important to understand exactly what is being tested. The statement “UDP works” is too weak: the real question is whether UDP traffic comes from the same address as TCP traffic. There are two ways this can fail, and both end in de-anonymization:
UDP traffic bypasses the proxy and is routed directly from the user device. The site then sees both the proxy address (over TCP) and the user's real address (via STUN or QUIC). This is the worst-case scenario: the user thinks they are protected, but in reality they are more exposed than they would be without a proxy at all.
UDP traffic is blocked entirely. There are no leaks, but a browser without WebRTC and QUIC is anomalous in itself, and anti-fraud systems can detect it.
Octo does neither. All six tests below show the same exit address for both TCP and UDP.
Contents
Maintain your online anonymity with Octo Browser. Your real digital fingerprint cannot be tracked.
Would you like to try Octo Browser at а discount?
Use the promo code OCTOBLOG to get 30% off any subscription. This offer is valid only for new users.
Test setup
Browser: Octo Browser 3.1.3 (Chromium 152).
Profile: Quick honorable-bar · ID 8dd7332…
Proxy (Elusive): SOCKS5 · 91.132.161.222:35225.
Exit address: 68.59.118.110 · USA · Comcast · Residential.
Date and time: September 10, 2026, 12:04–12:11.
How to read the screenshots
All six screenshots are from one continuous session, not six separate runs. You can see this from three things, and they are worth noting before looking at the tests themselves:
The same profile information appears at the top of every screenshot: Quick honorable-bar, ID 8dd7332…, proxy 91.132.161.222:35225, and a UDP badge showing 68.59.118.110. Octo displays the UDP exit address separately—that is the address that should appear in all the tests below.
The tabs were not closed. There is one tab in the first screenshot and six in the last, with the previous tests visible in the tab bar.
The system tray clock advances continuously: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.
There was no reconfiguration of the profile between tests.
Step 1. A call through the proxy. Twilio Network Test
September 10, 12:04. One tab—the session has just started.
The official diagnostic tool from Twilio, a major provider of voice and video communications. Developers use it to check whether a client's network can handle browser-based calls. It does not look for leaks and knows nothing about anti-detect browsers—it simply makes an actual call.
All checks passed, including TURN UDP Connectivity, which literally means that UDP packets from the browser reached Twilio's servers and came back. The test then made two actual calls using different codecs, PCMU and Opus: their identifiers, zero packet loss, and the final quality ratings—Great and Good—are visible in the log on the right.
The notes for the TCP and TLS checks are also worth reading. Twilio states there that Twilio Voice does not work over TCP at all. In other words, both successful calls were made over UDP—there was no other option.
Conclusion: two live voice calls passed through the SOCKS5 proxy with zero packet loss.
Step 2: QUIC works, and the address belongs to the proxy. BrowserLeaks
September 10, 12:04. There are now two tabs—Twilio is still open on the left.
A public QUIC test from BrowserLeaks. It answers two different questions at once, and we need both: does the browser support QUIC—that is, does UDP work—and which address the server sees us from over QUIC—that is, where the UDP traffic is going.
Step 1 already showed that UDP works, but that was a different kind of UDP. Twilio was testing WebRTC—UDP for calls. QUIC is UDP for ordinary web traffic. HTTP/3 runs on it, and Google and YouTube use it to communicate with browsers. The technologies are different, and support for one does not imply support for the other.
There are two results in the screenshot: QUIC Connection: True, which means that a connection over UDP was established, and IP Address: 68.59.118.110, which is the same address Octo shows in the profile bar as the UDP exit address.
Conclusion: the QUIC connection was established, and the server saw it coming from the proxy address.
Step 3: Four channels, one address. WebRTC Detection Check
September 10, 12:05. Third tab, with the two previous tests still open on the left.
The first two steps showed that UDP gets through and that the address is correct over QUIC. This test compares addresses across all channels at once and separately checks whether the browser is simulating WebRTC rather than actually running it.
There are four lines in the IP Sources section, representing four different ways of discovering our address: through a regular HTTP request (TCP), through a STUN server (UDP), through a TURN relay over UDP, and through the same TURN relay over TCP. All four lines show 68.59.118.110, our proxy address. In other words, the UDP address matches the TCP address.
Below that is the Detection Flags section, with seven separate checks for browser spoofing. All seven return NO:
WebRTC Blocked: WebRTC is not disabled; it works.
UDP/TCP Mismatch: there is no mismatch between the UDP and TCP addresses.
Candidates Spoofed: the ICE candidates the browser presents to its peer have not been spoofed.
TURN UDP Blocked and TURN TCP Blocked: relay traffic works in both directions.
Relay Spoofed: the relay is genuine.
The combination is what matters. The first flag shows that WebRTC is working; the other six show that nothing is being spoofed in the process. You cannot hide the problem simply by disabling WebRTC here: that would immediately show up in the very first line.
Conclusion: four independent channels—HTTP, STUN, TURN UDP, and TURN TCP—return the same address. None of the seven blocking or spoofing checks was triggered.
Step 4: 3,000 requests over HTTP/3. NGINX QUIC Sandbox
September 10, 12:07. Fourth tab.
A test environment from the nginx developers themselves. It sends a batch of requests and breaks the result down into three counters: how many went over QUIC, how many went over regular HTTP, and how many failed to get through at all.
Step 2 showed one QUIC connection. Here there are three thousand consecutive requests—this is no longer a test of whether QUIC is supported, but of whether the channel can handle sustained load.
Result: Total requests 3000, Success with QUIC 3000, Success with HTTP 0, Failed requests 0. Progress is 3000/3000, and the visualization beneath it is entirely green. Green represents QUIC, and there are no cells of any other color.
The Success with HTTP counter is worth noting too. It is specifically for requests that could not go over QUIC and fell back to regular HTTP. It shows zero.
Conclusion: 3,000 out of 3,000 requests went over QUIC. There was no fallback to regular HTTP and no failed requests.
Step 5: WebTransport shows the same address. wtcheck.top
September 10, 12:10. Fifth tab.
WebTransport is another browser-based way of exchanging data over QUIC, that is, over UDP. The page makes two requests and displays the results side by side: the address of the regular TCP request and the address of the WebTransport connection.
This is the third different way of testing UDP traffic: Step 1 used WebRTC; Steps 2 and 4 used QUIC and HTTP/3; here we look at WebTransport. Each additional test narrows the scope for the objection “ok, this particular protocol works, but what about the others?”
Both fields show 68.59.118.110. There is no need to compare anything between screenshots, as the two values are displayed on the same page.
Conclusion: the WebTransport connection came from the same address as the regular TCP request from the same page.
Step 6: DNS resolves on the proxy side. BrowserLeaks
September 10, 12:11. Sixth tab, with all previous tests still open on the left.
DNS is a channel separate from all the traffic discussed above. A proxy can be configured perfectly, while the browser may still ask the local provider's resolver, “What is the address of site X?” This has two consequences: the provider can see the browsing history, and the site can compare the resolver's geography with the geography of the IP address and spot a discrepancy.
The test checks which DNS servers participated in the resolution. In the screenshot you can see the following: address 68.59.118.110, provider Comcast, and the result Found 77 Servers, 1 ISP. In the visible part of the list, the resolvers are in the 69.241.83.x range, and each one has the same Comcast listed as its ISP.
The key figure is 1 ISP. Every single resolver belongs to the same provider as the proxy's exit address. No request went to a resolver belonging to a different provider.
Conclusion: all 77 DNS servers belong to the exit node's provider. DNS resolution happens on the proxy side; the local resolver is not involved.
How to reproduce the test yourself
Create an Octo profile and connect your SOCKS5 proxy with UDP support to it. Launch the profile and open the six links below. Look at the resulting address. In every test, it should match the address Octo displays next to the UDP badge.
networktest.twilio.com: a WebRTC call. Does UDP reach the voice provider's servers?
browserleaks.com/quic: Does QUIC work, and which address does it come from?
ipbinding.notsosmart.dev compares the addresses over HTTP, STUN, TURN UDP, and TURN TCP and displays spoofing flags.
quic.nginx.org/quic.html: can the channel handle sustained load: 3,000 HTTP/3 requests?
wtcheck.top: does the WebTransport address match the TCP address?
browserleaks.com/dns: who owns the resolvers involved in determining the addresses?
Maintain your online anonymity with Octo Browser. Your real digital fingerprint cannot be tracked.
Would you like to try Octo Browser at а discount?
Use the promo code OCTOBLOG to get 30% off any subscription. This offer is valid only for new users.
Test setup
Browser: Octo Browser 3.1.3 (Chromium 152).
Profile: Quick honorable-bar · ID 8dd7332…
Proxy (Elusive): SOCKS5 · 91.132.161.222:35225.
Exit address: 68.59.118.110 · USA · Comcast · Residential.
Date and time: September 10, 2026, 12:04–12:11.
How to read the screenshots
All six screenshots are from one continuous session, not six separate runs. You can see this from three things, and they are worth noting before looking at the tests themselves:
The same profile information appears at the top of every screenshot: Quick honorable-bar, ID 8dd7332…, proxy 91.132.161.222:35225, and a UDP badge showing 68.59.118.110. Octo displays the UDP exit address separately—that is the address that should appear in all the tests below.
The tabs were not closed. There is one tab in the first screenshot and six in the last, with the previous tests visible in the tab bar.
The system tray clock advances continuously: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.
There was no reconfiguration of the profile between tests.
Step 1. A call through the proxy. Twilio Network Test
September 10, 12:04. One tab—the session has just started.
The official diagnostic tool from Twilio, a major provider of voice and video communications. Developers use it to check whether a client's network can handle browser-based calls. It does not look for leaks and knows nothing about anti-detect browsers—it simply makes an actual call.
All checks passed, including TURN UDP Connectivity, which literally means that UDP packets from the browser reached Twilio's servers and came back. The test then made two actual calls using different codecs, PCMU and Opus: their identifiers, zero packet loss, and the final quality ratings—Great and Good—are visible in the log on the right.
The notes for the TCP and TLS checks are also worth reading. Twilio states there that Twilio Voice does not work over TCP at all. In other words, both successful calls were made over UDP—there was no other option.
Conclusion: two live voice calls passed through the SOCKS5 proxy with zero packet loss.
Step 2: QUIC works, and the address belongs to the proxy. BrowserLeaks
September 10, 12:04. There are now two tabs—Twilio is still open on the left.
A public QUIC test from BrowserLeaks. It answers two different questions at once, and we need both: does the browser support QUIC—that is, does UDP work—and which address the server sees us from over QUIC—that is, where the UDP traffic is going.
Step 1 already showed that UDP works, but that was a different kind of UDP. Twilio was testing WebRTC—UDP for calls. QUIC is UDP for ordinary web traffic. HTTP/3 runs on it, and Google and YouTube use it to communicate with browsers. The technologies are different, and support for one does not imply support for the other.
There are two results in the screenshot: QUIC Connection: True, which means that a connection over UDP was established, and IP Address: 68.59.118.110, which is the same address Octo shows in the profile bar as the UDP exit address.
Conclusion: the QUIC connection was established, and the server saw it coming from the proxy address.
Step 3: Four channels, one address. WebRTC Detection Check
September 10, 12:05. Third tab, with the two previous tests still open on the left.
The first two steps showed that UDP gets through and that the address is correct over QUIC. This test compares addresses across all channels at once and separately checks whether the browser is simulating WebRTC rather than actually running it.
There are four lines in the IP Sources section, representing four different ways of discovering our address: through a regular HTTP request (TCP), through a STUN server (UDP), through a TURN relay over UDP, and through the same TURN relay over TCP. All four lines show 68.59.118.110, our proxy address. In other words, the UDP address matches the TCP address.
Below that is the Detection Flags section, with seven separate checks for browser spoofing. All seven return NO:
WebRTC Blocked: WebRTC is not disabled; it works.
UDP/TCP Mismatch: there is no mismatch between the UDP and TCP addresses.
Candidates Spoofed: the ICE candidates the browser presents to its peer have not been spoofed.
TURN UDP Blocked and TURN TCP Blocked: relay traffic works in both directions.
Relay Spoofed: the relay is genuine.
The combination is what matters. The first flag shows that WebRTC is working; the other six show that nothing is being spoofed in the process. You cannot hide the problem simply by disabling WebRTC here: that would immediately show up in the very first line.
Conclusion: four independent channels—HTTP, STUN, TURN UDP, and TURN TCP—return the same address. None of the seven blocking or spoofing checks was triggered.
Step 4: 3,000 requests over HTTP/3. NGINX QUIC Sandbox
September 10, 12:07. Fourth tab.
A test environment from the nginx developers themselves. It sends a batch of requests and breaks the result down into three counters: how many went over QUIC, how many went over regular HTTP, and how many failed to get through at all.
Step 2 showed one QUIC connection. Here there are three thousand consecutive requests—this is no longer a test of whether QUIC is supported, but of whether the channel can handle sustained load.
Result: Total requests 3000, Success with QUIC 3000, Success with HTTP 0, Failed requests 0. Progress is 3000/3000, and the visualization beneath it is entirely green. Green represents QUIC, and there are no cells of any other color.
The Success with HTTP counter is worth noting too. It is specifically for requests that could not go over QUIC and fell back to regular HTTP. It shows zero.
Conclusion: 3,000 out of 3,000 requests went over QUIC. There was no fallback to regular HTTP and no failed requests.
Step 5: WebTransport shows the same address. wtcheck.top
September 10, 12:10. Fifth tab.
WebTransport is another browser-based way of exchanging data over QUIC, that is, over UDP. The page makes two requests and displays the results side by side: the address of the regular TCP request and the address of the WebTransport connection.
This is the third different way of testing UDP traffic: Step 1 used WebRTC; Steps 2 and 4 used QUIC and HTTP/3; here we look at WebTransport. Each additional test narrows the scope for the objection “ok, this particular protocol works, but what about the others?”
Both fields show 68.59.118.110. There is no need to compare anything between screenshots, as the two values are displayed on the same page.
Conclusion: the WebTransport connection came from the same address as the regular TCP request from the same page.
Step 6: DNS resolves on the proxy side. BrowserLeaks
September 10, 12:11. Sixth tab, with all previous tests still open on the left.
DNS is a channel separate from all the traffic discussed above. A proxy can be configured perfectly, while the browser may still ask the local provider's resolver, “What is the address of site X?” This has two consequences: the provider can see the browsing history, and the site can compare the resolver's geography with the geography of the IP address and spot a discrepancy.
The test checks which DNS servers participated in the resolution. In the screenshot you can see the following: address 68.59.118.110, provider Comcast, and the result Found 77 Servers, 1 ISP. In the visible part of the list, the resolvers are in the 69.241.83.x range, and each one has the same Comcast listed as its ISP.
The key figure is 1 ISP. Every single resolver belongs to the same provider as the proxy's exit address. No request went to a resolver belonging to a different provider.
Conclusion: all 77 DNS servers belong to the exit node's provider. DNS resolution happens on the proxy side; the local resolver is not involved.
How to reproduce the test yourself
Create an Octo profile and connect your SOCKS5 proxy with UDP support to it. Launch the profile and open the six links below. Look at the resulting address. In every test, it should match the address Octo displays next to the UDP badge.
networktest.twilio.com: a WebRTC call. Does UDP reach the voice provider's servers?
browserleaks.com/quic: Does QUIC work, and which address does it come from?
ipbinding.notsosmart.dev compares the addresses over HTTP, STUN, TURN UDP, and TURN TCP and displays spoofing flags.
quic.nginx.org/quic.html: can the channel handle sustained load: 3,000 HTTP/3 requests?
wtcheck.top: does the WebTransport address match the TCP address?
browserleaks.com/dns: who owns the resolvers involved in determining the addresses?
Stay up to date with the latest Octo Browser news
By clicking the button you agree to our Privacy Policy.
Stay up to date with the latest Octo Browser news
By clicking the button you agree to our Privacy Policy.
Stay up to date with the latest Octo Browser news
By clicking the button you agree to our Privacy Policy.
Join Octo Browser now
Or contact Customer Service at any time with any questions you might have.
Join Octo Browser now
Or contact Customer Service at any time with any questions you might have.
Join Octo Browser now
Or contact Customer Service at any time with any questions you might have.