基于 SOCKS5 的 UDP：六项测试、一个配置文件、一个 IP 地址
Sophia Grote
Support specialist, Octo Browser
Octo Browser 支持基于 SOCKS5 的 UDP，这意味着 WebRTC、QUIC、HTTP/3 和 WebTransport 会通过代理传输，而不是绕过代理。我们想看看实际情况是否确实如此。
准确理解正在测试的内容非常重要。“UDP 可以工作”这一表述太笼统了：真正的问题是 UDP 流量是否与 TCP 流量来自同一个地址。这可能会在两种情况下失效，而这两种情况最终都会导致去匿名化：
UDP 流量绕过代理并直接从用户设备路由。然后，网站会同时看到代理地址（通过 TCP）和用户的真实地址（通过 STUN 或 QUIC）。这是最糟糕的情况：用户认为自己受到了保护，但实际上他们比完全不用代理暴露得更彻底。
UDP 流量被完全阻止。虽然没有泄漏，但没有 WebRTC 和 QUIC 的浏览器本身就是异常的，反欺诈系统可以检测到它。
Octo 两者皆非。以下所有六项测试均显示 TCP 和 UDP 具有相同的出口地址。
内容
使用Octo Browser维护您的在线匿名性。您真实的数字指纹无法被追踪。
想以优惠价试用 Octo 浏览器吗？
使用优惠码 OCTOBLOG，即可享受任意订阅 30% 折扣。此优惠仅限新用户使用。
测试设置
浏览器：Octo Browser 3.1.3 (Chromium 152)。
配置文件：Quick honorable-bar · ID 8dd7332…
代理 (Elusive)：SOCKS5 · 91.132.161.222:35225。
出口地址：68.59.118.110 · 美国 · Comcast · 住宅。
日期与时间：2026年9月10日，12:04–12:11。
如何解读截图
所有六张截图均来自同一个连续会话，而非六次单独的运行。您可以从以下三点看出这一点，在查看测试本身之前值得注意：
每张截图顶部都显示相同的配置文件信息：Quick honorable-bar、ID 8dd7332…、代理 91.132.161.222:35225，以及显示为 68.59.118.110 的 UDP 徽标。Octo 会单独显示 UDP 出口地址——该地址应出现在以下所有测试中。
标签页并未关闭。第一张截图中有 1 个标签页，最后一张截图中有 6 个，标签栏中可以看到之前的测试。
系统托盘时钟连续递增：12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11。
测试之间没有重新配置配置文件。
步骤 1. 通过代理进行呼叫。Twilio Network Test
9月10日，12:04。一个标签页——会话刚刚开始。
来自主要语音和视频通信提供商 Twilio 的官方诊断工具。开发者使用它来检查客户端网络是否可以处理基于浏览器的通话。它不查找泄漏，对反检测浏览器一无所知——它只是发起一次实际通话。
所有检查均已通过，包括 TURN UDP Connectivity，这字面意思是指来自浏览器的 UDP 数据包已到达 Twilio 的服务器并返回。随后测试使用不同的编解码器 PCMU 和 Opus 发起了两次实际通话：它们的标识符、零丢包率以及最终质量评级（Great 和 Good）均可在右侧日志中看到。
TCP 和 TLS 检查的说明也值得一读。Twilio 在其中声明 Twilio Voice 完全无法在 TCP 上运行。换句话说，两次成功的通话都是通过 UDP 进行的——别无选择。
结论：两次实时语音通话均通过 SOCKS5 代理进行，丢包率为零。
步骤 2：QUIC 正常工作，且地址属于代理。BrowserLeaks
9月10日，12:04。现在有两个标签页——左侧仍打开着 Twilio。
来自 BrowserLeaks 的公开 QUIC 测试。它同时回答了两个不同的问题，而这两个问题我们都需要：浏览器是否支持 QUIC（即 UDP 是否正常工作），以及服务器在 QUIC 上看到的我们的地址是什么（即 UDP 流量去往何处）。
步骤 1 已经表明 UDP 正常工作，但那是另一种 UDP。Twilio 测试的是 WebRTC——用于通话的 UDP。QUIC 则是用于普通网络流量的 UDP。HTTP/3 在其上运行，Google 和 YouTube 也使用它与浏览器通信。这两项技术有所不同，支持其中一种并不意味着支持另一种。
截图中显示了两个结果：QUIC Connection: True，表示已建立基于 UDP 的连接；以及 IP Address: 68.59.118.110，这与 Octo 在配置文件栏中显示的 UDP 出口地址相同。
结论：QUIC 连接已成功建立，且服务器看到的连接来自代理地址。
步骤 3：四个通道，一个地址。WebRTC Detection Check
9月10日，12:05。第三个标签页，左侧仍打开着前两次测试。
前两个步骤表明 UDP 可以顺利传输，并且在 QUIC 上的地址是正确的。该测试同时对比所有通道的地址，并单独检查浏览器是否在模拟 WebRTC 而非实际运行它。
IP Sources 部分有四行，代表发现我们地址的四种不同方式：通过常规 HTTP 请求 (TCP)、通过 STUN 服务器 (UDP)、通过基于 UDP 的 TURN 中继，以及通过基于 TCP 的同一 TURN 中继。所有四行均显示 68.59.118.110，即我们的代理地址。换句话说，UDP 地址与 TCP 地址一致。
其下方是 Detection Flags 部分，包含针对浏览器伪造的七项独立检查。所有七项均返回 NO：
WebRTC Blocked：WebRTC 未被禁用；它正常工作。
UDP/TCP Mismatch：UDP 和 TCP 地址之间不存在不匹配。
Candidates Spoofed：浏览器呈现给其对等端的 ICE 候选者未被伪造。
TURN UDP Blocked 和 TURN TCP Blocked：中继流量双向正常工作。
Relay Spoofed：中继是真实的。
关键在于组合。第一个标志表明 WebRTC 正在工作；其他六个标志表明在此过程中没有发生任何伪造。您无法通过在此简单地禁用 WebRTC 来掩盖问题：这会立即显示在第一行中。
结论：四个独立通道——HTTP、STUN、TURN UDP 和 TURN TCP——返回相同的地址。未触发七项阻止或伪造检查中的任何一项。
步骤 4：通过 HTTP/3 发送 3,000 个请求。NGINX QUIC Sandbox
9月10日，12:07。第四个标签页。
来自 nginx 开发者自己的测试环境。它发送一批请求并将结果细分为三个计数器：有多少通过 QUIC 进行，有多少通过常规 HTTP 进行，以及有多少根本未能通过。
步骤 2 显示了一个 QUIC 连接。这里有三千个连续请求——这不再是测试是否支持 QUIC，而是测试该通道是否能承受持续负载。
结果：Total requests 3000，Success with QUIC 3000，Success with HTTP 0，Failed requests 0。进度为 3000/3000，其下方的可视化图表完全呈绿色。绿色代表 QUIC，没有任何其他颜色的单元格。
Success with HTTP 计数器也值得注意。它专门用于统计无法通过 QUIC 发送并回退到常规 HTTP 的请求。它显示为零。
结论：3,000 个请求中有 3,000 个通过 QUIC 进行。没有回退到常规 HTTP，也没有失败的请求。
步骤 5：WebTransport 显示相同的地址。wtcheck.top
9月10日，12:10。第五个标签页。
WebTransport 是另一种基于浏览器通过 QUIC（即通过 UDP）交换数据的方式。该页面发出两个请求并并排显示结果：常规 TCP 请求的地址和 WebTransport 连接的地址。
这是测试 UDP 流量的第三种不同方式：步骤 1 使用了 WebRTC；步骤 2 和 4 使用了 QUIC 和 HTTP/3；在这里我们查看 WebTransport。每增加一次测试，都会缩小诸如“好吧，这个特定协议可以工作，但其他协议呢？”这类质疑的空间。
两个字段均显示 68.59.118.110。无需在截图之间进行任何比较，因为这两个值显示在同一页面上。
结论：WebTransport 连接来自与同一页面常规 TCP 请求相同的地址。
步骤 6：DNS 在代理端解析。BrowserLeaks
9月10日，12:11。第六个标签页，左侧仍打开着之前的所有测试。
DNS 是一个独立于上述所有流量的通道。代理可以配置得很完美，而浏览器仍可能向本地提供商的解析器询问：“网站 X 的地址是什么？”这会产生两个后果：提供商可以看到浏览历史记录，并且网站可以将解析器的地理位置与 IP 地址的地理位置进行比较并发现差异。
该测试检查哪些 DNS 服务器参与了解析。在截图中您可以看到以下内容：地址 68.59.118.110，提供商 Comcast，以及结果 Found 77 Servers, 1 ISP。在列表的可见部分中，解析器位于 69.241.83.x 范围内，并且每一个都将同一个 Comcast 列为其 ISP。
关键数字是 1 ISP。每一个解析器都属于代理出口地址的同一提供商。没有请求发送给属于不同提供商的解析器。
结论：所有 77 台 DNS 服务器均属于出口节点的提供商。DNS 解析在代理端进行；本地解析器未参与。
如何自行复现测试
创建一个 Octo 配置文件，并将支持 UDP 的 SOCKS5 代理连接到该文件。启动配置文件并打开以下六个链接。查看生成的地址。在每次测试中，它都应与 Octo 在 UDP 徽标旁显示的地址相匹配。
networktest.twilio.com：WebRTC 通话。UDP 是否能到达语音提供商的服务器？
browserleaks.com/quic：QUIC 是否正常工作，它来自哪个地址？
ipbinding.notsosmart.dev 比较通过 HTTP、STUN、TURN UDP 和 TURN TCP 的地址，并显示伪造标志。
quic.nginx.org/quic.html：通道能否承受持续负载：3,000 个 HTTP/3 请求？
wtcheck.top：WebTransport 地址是否与 TCP 地址匹配？
browserleaks.com/dns：参与确定地址的解析器归谁所有？
使用Octo Browser维护您的在线匿名性。您真实的数字指纹无法被追踪。
想以优惠价试用 Octo 浏览器吗？
使用优惠码 OCTOBLOG，即可享受任意订阅 30% 折扣。此优惠仅限新用户使用。
测试设置
浏览器：Octo Browser 3.1.3 (Chromium 152)。
配置文件：Quick honorable-bar · ID 8dd7332…
代理 (Elusive)：SOCKS5 · 91.132.161.222:35225。
出口地址：68.59.118.110 · 美国 · Comcast · 住宅。
日期与时间：2026年9月10日，12:04–12:11。
如何解读截图
所有六张截图均来自同一个连续会话，而非六次单独的运行。您可以从以下三点看出这一点，在查看测试本身之前值得注意：
每张截图顶部都显示相同的配置文件信息：Quick honorable-bar、ID 8dd7332…、代理 91.132.161.222:35225，以及显示为 68.59.118.110 的 UDP 徽标。Octo 会单独显示 UDP 出口地址——该地址应出现在以下所有测试中。
标签页并未关闭。第一张截图中有 1 个标签页，最后一张截图中有 6 个，标签栏中可以看到之前的测试。
系统托盘时钟连续递增：12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11。
测试之间没有重新配置配置文件。
步骤 1. 通过代理进行呼叫。Twilio Network Test
9月10日，12:04。一个标签页——会话刚刚开始。
来自主要语音和视频通信提供商 Twilio 的官方诊断工具。开发者使用它来检查客户端网络是否可以处理基于浏览器的通话。它不查找泄漏，对反检测浏览器一无所知——它只是发起一次实际通话。
所有检查均已通过，包括 TURN UDP Connectivity，这字面意思是指来自浏览器的 UDP 数据包已到达 Twilio 的服务器并返回。随后测试使用不同的编解码器 PCMU 和 Opus 发起了两次实际通话：它们的标识符、零丢包率以及最终质量评级（Great 和 Good）均可在右侧日志中看到。
TCP 和 TLS 检查的说明也值得一读。Twilio 在其中声明 Twilio Voice 完全无法在 TCP 上运行。换句话说，两次成功的通话都是通过 UDP 进行的——别无选择。
结论：两次实时语音通话均通过 SOCKS5 代理进行，丢包率为零。
步骤 2：QUIC 正常工作，且地址属于代理。BrowserLeaks
9月10日，12:04。现在有两个标签页——左侧仍打开着 Twilio。
来自 BrowserLeaks 的公开 QUIC 测试。它同时回答了两个不同的问题，而这两个问题我们都需要：浏览器是否支持 QUIC（即 UDP 是否正常工作），以及服务器在 QUIC 上看到的我们的地址是什么（即 UDP 流量去往何处）。
步骤 1 已经表明 UDP 正常工作，但那是另一种 UDP。Twilio 测试的是 WebRTC——用于通话的 UDP。QUIC 则是用于普通网络流量的 UDP。HTTP/3 在其上运行，Google 和 YouTube 也使用它与浏览器通信。这两项技术有所不同，支持其中一种并不意味着支持另一种。
截图中显示了两个结果：QUIC Connection: True，表示已建立基于 UDP 的连接；以及 IP Address: 68.59.118.110，这与 Octo 在配置文件栏中显示的 UDP 出口地址相同。
结论：QUIC 连接已成功建立，且服务器看到的连接来自代理地址。
步骤 3：四个通道，一个地址。WebRTC Detection Check
9月10日，12:05。第三个标签页，左侧仍打开着前两次测试。
前两个步骤表明 UDP 可以顺利传输，并且在 QUIC 上的地址是正确的。该测试同时对比所有通道的地址，并单独检查浏览器是否在模拟 WebRTC 而非实际运行它。
IP Sources 部分有四行，代表发现我们地址的四种不同方式：通过常规 HTTP 请求 (TCP)、通过 STUN 服务器 (UDP)、通过基于 UDP 的 TURN 中继，以及通过基于 TCP 的同一 TURN 中继。所有四行均显示 68.59.118.110，即我们的代理地址。换句话说，UDP 地址与 TCP 地址一致。
其下方是 Detection Flags 部分，包含针对浏览器伪造的七项独立检查。所有七项均返回 NO：
WebRTC Blocked：WebRTC 未被禁用；它正常工作。
UDP/TCP Mismatch：UDP 和 TCP 地址之间不存在不匹配。
Candidates Spoofed：浏览器呈现给其对等端的 ICE 候选者未被伪造。
TURN UDP Blocked 和 TURN TCP Blocked：中继流量双向正常工作。
Relay Spoofed：中继是真实的。
关键在于组合。第一个标志表明 WebRTC 正在工作；其他六个标志表明在此过程中没有发生任何伪造。您无法通过在此简单地禁用 WebRTC 来掩盖问题：这会立即显示在第一行中。
结论：四个独立通道——HTTP、STUN、TURN UDP 和 TURN TCP——返回相同的地址。未触发七项阻止或伪造检查中的任何一项。
步骤 4：通过 HTTP/3 发送 3,000 个请求。NGINX QUIC Sandbox
9月10日，12:07。第四个标签页。
来自 nginx 开发者自己的测试环境。它发送一批请求并将结果细分为三个计数器：有多少通过 QUIC 进行，有多少通过常规 HTTP 进行，以及有多少根本未能通过。
步骤 2 显示了一个 QUIC 连接。这里有三千个连续请求——这不再是测试是否支持 QUIC，而是测试该通道是否能承受持续负载。
结果：Total requests 3000，Success with QUIC 3000，Success with HTTP 0，Failed requests 0。进度为 3000/3000，其下方的可视化图表完全呈绿色。绿色代表 QUIC，没有任何其他颜色的单元格。
Success with HTTP 计数器也值得注意。它专门用于统计无法通过 QUIC 发送并回退到常规 HTTP 的请求。它显示为零。
结论：3,000 个请求中有 3,000 个通过 QUIC 进行。没有回退到常规 HTTP，也没有失败的请求。
步骤 5：WebTransport 显示相同的地址。wtcheck.top
9月10日，12:10。第五个标签页。
WebTransport 是另一种基于浏览器通过 QUIC（即通过 UDP）交换数据的方式。该页面发出两个请求并并排显示结果：常规 TCP 请求的地址和 WebTransport 连接的地址。
这是测试 UDP 流量的第三种不同方式：步骤 1 使用了 WebRTC；步骤 2 和 4 使用了 QUIC 和 HTTP/3；在这里我们查看 WebTransport。每增加一次测试，都会缩小诸如“好吧，这个特定协议可以工作，但其他协议呢？”这类质疑的空间。
两个字段均显示 68.59.118.110。无需在截图之间进行任何比较，因为这两个值显示在同一页面上。
结论：WebTransport 连接来自与同一页面常规 TCP 请求相同的地址。
步骤 6：DNS 在代理端解析。BrowserLeaks
9月10日，12:11。第六个标签页，左侧仍打开着之前的所有测试。
DNS 是一个独立于上述所有流量的通道。代理可以配置得很完美，而浏览器仍可能向本地提供商的解析器询问：“网站 X 的地址是什么？”这会产生两个后果：提供商可以看到浏览历史记录，并且网站可以将解析器的地理位置与 IP 地址的地理位置进行比较并发现差异。
该测试检查哪些 DNS 服务器参与了解析。在截图中您可以看到以下内容：地址 68.59.118.110，提供商 Comcast，以及结果 Found 77 Servers, 1 ISP。在列表的可见部分中，解析器位于 69.241.83.x 范围内，并且每一个都将同一个 Comcast 列为其 ISP。
关键数字是 1 ISP。每一个解析器都属于代理出口地址的同一提供商。没有请求发送给属于不同提供商的解析器。
结论：所有 77 台 DNS 服务器均属于出口节点的提供商。DNS 解析在代理端进行；本地解析器未参与。
如何自行复现测试
创建一个 Octo 配置文件，并将支持 UDP 的 SOCKS5 代理连接到该文件。启动配置文件并打开以下六个链接。查看生成的地址。在每次测试中，它都应与 Octo 在 UDP 徽标旁显示的地址相匹配。
networktest.twilio.com：WebRTC 通话。UDP 是否能到达语音提供商的服务器？
browserleaks.com/quic：QUIC 是否正常工作，它来自哪个地址？
ipbinding.notsosmart.dev 比较通过 HTTP、STUN、TURN UDP 和 TURN TCP 的地址，并显示伪造标志。
quic.nginx.org/quic.html：通道能否承受持续负载：3,000 个 HTTP/3 请求？
wtcheck.top：WebTransport 地址是否与 TCP 地址匹配？
browserleaks.com/dns：参与确定地址的解析器归谁所有？
随时获取最新的Octo Browser新闻
通过点击按钮，您同意我们的 隐私政策。
随时获取最新的Octo Browser新闻
通过点击按钮，您同意我们的 隐私政策。
随时获取最新的Octo Browser新闻
通过点击按钮，您同意我们的 隐私政策。
