WebRTC泄露测试：https://browserleaks.com/webrtc
NAT类型测试工具：https://github.com/HMBSbige/NatTypeTester
=====游戏必备稳定高速精品VPS线路=====
美国GIA：http://us.bulianglin.com
香港GIA：http://hk.bulianglin.com
日本GIA：http://jp.bulianglin.com

视频教程

视频地址：https://youtu.be/GQg5JIQIjgk

在DNS泄露那期视频的最后
我们简单的了解了一下
WebRTC会泄露你的真实IP
通过浏览器插件禁用WebRTC来阻止泄露
上次没有跟大家说明
为什么会有WebRTC泄露
是因为和今天要讲的UDP有关
如果是无法安装插件的手机端
该如何阻止WebRTC泄漏
什么是原生UDP
什么又是UoT
代理UDP的一个最主要的应用场景
就是玩国际服的游戏
那么对于玩游戏而言
使用原生UDP好还是使用UoT好
P2P联机的fullcone是个啥
QUIC又是个啥
本期就来给大家解答
UDP在代理中的各种疑惑
UDP和TCP同属传输层
可以说是两个特性完全
相反的传输协议
由于我们并不是讲网络课程
所以没必要细究
我们只需要知道TCP是可靠传输
也就是你发出去的数据
对方一定能收到
如果丢失了也会想办法补发
并且发送数据前
要先进行3次握手建立连接
最常见的就是我们上网使用的HTTP
协议而UDP是不可靠的传输
对方不一定能收到数据包丢了就丢了
也不用握手建立连接
直接就能开始发送数据
最常见的应用就是
要求响应速度快的DNS
以及对丢包不敏感的音视频通话
还有对延迟敏感的即时对战网络游戏
接下来就来详细探讨一下UDP
在代理中的行为
先来回顾上节内容创建一个最常见的家庭网络环境
你在运营商拉了一条宽带
他会给你分配一个光猫
一般来讲
你会单独再买一个路由器连接光猫
路由器通过PPPOE拨号
获取运营商分配的公网IP
同时路由器作为局域网的网关
会有自己的内网IP
家里的所有网络设备
都会连接到这台路由器
路由器通过DHCP
为每一台网络设备分配一个内网IP
以及默认网关DNS等信息
一般情况下
默认网关和DNS服务器都是路由器
这是最常见的家庭网络拓扑
以之前讲过的系统代理为例
你在电脑上运行了V2rayN
或者clash for windows
此时浏览器访问检测IP的网站
由于设置了系统代理
请求数据会交给clash
clash将数据使用你的SS
或者Vmess配置进行加密
然后发给节点服务器处理
详细流程前面已经都讲过了
这里就不再啰嗦了
最终
clash会收到节点服务器返回的数据
经过解密后将数据返回给浏览器
通过浏览器的渲染
将网页呈现在我们的面前
由于是节点服务器帮我们访问的
所以查询到的ip地址是香港的IP
这个流程相信大家都已经很清楚了
接下来访问检测WebRTC泄露的网站
流程和刚才查询IP是一样的
但是和预期的结果不一样
网页中返回了真实的国内IP
而不是节点的香港IP
并且
我已经将Clash设置为全局模式了
却还是暴露了国内IP
这到底是怎么回事
其实我们在打开一个网页的时候
并不是只发起一个HTTP请求
通过F12
我们可以调出浏览器的开发者面板
可以看到打开一个普通的网页
会发起几十甚至上百个HTTP请求
以加载不同的资源
比如js代码 网页图片等信息
而这个网页比较特殊
他要检测WebRTC泄漏
所以会发起一条stun请求
以建立WebRTC连接
而stun协议一般情况下使用UDP传输
所以浏览器发起了一条UDP的请求
但是系统代理一般是HTTP代理
HTTP代理是不支持代理UDP数据的
所以这条UDP的请求没有交给clash
也就是说即使clash开启了全局模式
但是这条请求压根就没有交给clash
而是通过直连发起的
在开发者面板中看不到WebRTC的请求
可以通过抓包工具wireshark查看
开启抓包后刷新网页试试
可以看到这是一条UDP请求的stun数据
stun主要用于协助P2P打洞
它会把你的公网IP返回给你
因为走的是直连
所以得到了你国内的公网ip地址
这就是导致WebRTC泄露真实IP的原因
UDP的流量根本就没有走代理
有些朋友可能知道
socks5协议支持代理UDP
如果我通过浏览器插件switchOmega
将浏览器的代理配置为clash监听的socks5
能防止WebRTC泄露吗
答案是并不可以
虽然socks5支持代理UDP
插件中配置的也确实是socks5代理
但是
浏览器不支持将UDP流量交给socks5代理
Chrome Firefox
Edge Safari这些主流的浏览器都不支持
所以即使你给浏览器配置的是
支持代理UDP数据的socks5代理
但UDP的请求还是走直连
则还是存在泄露
所以如果是使用系统代理的方式
不管是HTTP代理还是socks5代理
都无法解决这个问题
只能通过之前讲的
使用插件禁用浏览器的WebRTC功能
而如果你使用的是透明代理
比如使用软路由
或者Tun模式接管系统全局流量
又是另一种情况了
浏览器没有设置系统代理
不过即使有设置系统代理
根据刚才讲的
UDP的请求也不会走系统代理
而是直接发出
由于开启了Tun模式
stun的数据
会被路由到clash的虚拟网卡
这里不理解的话可以回看代理篇
clash根据分流规则
选择代理这条UDP请求
于是使用你配置的节点信息
将数据加密
假设使用SS节点
数据加密后
由clash通过UDP协议
将数据发送给节点服务器
节点服务器收到数据后进行解密
再帮我们访问stun服务器
stun服务器收到的数据将是
节点服务器的公网IP
这样就解决了WebRTC泄露的问题
其实就是让UDP流量走代理而已
所以这个页面也可以用来
判断你的节点是否启用了UDP代理
假设我现在关闭clash的系统代理
启用Tun模式接管系统全局流量
此时我再重新访问测试网站页面
正常情况下
列表里会显示节点服务器的IP
但是我这里是不正常的情况
还是显示了我国内的IP
说明我的UDP数据没有走代理
此时需要在log面板中查看日志
来排查这个问题
过滤UDP的请求
可以看到
访问stun服务器提示
没有匹配任何规则
于是走了直连
这个提示有迷惑性
其实并不是没有匹配规则
而是节点没有开启UDP代理功能
可以看到
当前选中的香港1节点
和其他节点的区别在于
没有UDP的标识
意思是没有开启UDP代理
可以通过编辑订阅文件来启用
将UDP的false改成true
保存后就能看到节点的UDP标识了
回到log面板
此时刷新页面
可以看到列表中已经变成香港的IP了
并且日志中也可以看到
stun服务器的请求交给了香港1的节点处理
这样就解决了WebRTC泄漏的问题了
这里要再补充一点
如果你在没有禁用WebRTC的情况下
检测结果为n/a
没有返回公网IP
大概率是节点服务器关闭了UDP代理
比如我用这个香港2的socks5节点
我在本地开启了UDP代理
可以看到这个UDP标识
也就是说
clash会把UDP的数据交给这个节点
此时再来访问测试网址
可以看到直接返回了n/a
没有检测到公网IP
因为这个节点关闭了UDP代理
收到UDP数据后并不会帮你访问
而是直接丢弃
可以在日志中看到
我的UDP数据
确实是交给了香港2的节点
而我这个香港2的socks5节点
其实是用V2rayN开启的
可以看到
V2rayN收到clash的UDP请求后
提示UDP没有启用
直接reject丢弃
可以在参数设置中
将开启UDP选项勾选
此时clash发过来的UDP数据就能被
正常代理了
可以看到
测试网站也正常的返回了节点IP
所以要成功代理UDP数据
除了本地的代理工具要开启UDP代理
节点服务器也要支持代理UDP才行
大家可以通过这个测试页面
来判断你的UDP
数据是否能被正常代理
有些代理工具默认不代理UDP数据
需要手动开启
比如iOS的小火箭
需要开启UDP转发
才能正常代理UDP数据
否则UDP数据会走直连
另外可以看到
小火箭的SS节点有个UDP over TCP的功能选项
这个是干嘛的
我们刚才演示的是SS节点
和socks5节点代理UDP数据的情况
clash加密UDP数据后
会直接通过UDP
将数据发送给节点服务器
这种叫原生UDP
而我们平时使用的vmess vless trojan
默认都是UDP over TCP
简称UoT
顾名思义就是在TCP中传输UDP
以Vmess为例
浏览器的UDP
请求通过虚拟网卡交给了clash
clash拿到数据后使用Vmess协议进行加密
Vmess会标识里面的是UDP的数据
然后将Vmess的数据使用TCP进行封装
再发给节点服务器
节点服务器收到TCP的数据后
进行解密
得到了浏览器的UDP请求
于是帮我们使用UDP协议
访问目标服务器
这种行为就是UoT
另外我们之前在节点搭建系列讲过
Vmess可以交给不同的
底层传输协议进行传输
比如基于UDP的KCP协议或者QUIC协议
虽然最后是通过UDP
将Vmess交给节点服务器
但这种行为并不是原生UDP
数据被封装在KCP或者QUIC里
他们并没有原生UDP的那些特性
比如不可靠传输
所以
目前代理UDP的方式主要分为两种
一种是socks5和SS的原生UDP
另一种是vmess vless trojan等协议使用的UoT
而小火箭给SS
协议的节点提供了UoT的功能
也就是不用原生UDP了
改成UoT
xray和sing-box也有这样的功能
这个功能是开发sing-box的大佬写的
为什么要这么做
原生UDP不好吗
在某些情况下确实不好
比如你的节点线路很烂
使用原生UDP的话
会被运营商疯狂的QoS
因为UDP不像TCP那样有拥塞控制机制
TCP在链路拥堵的情况下
会主动降低发送速率
UDP可不管这些
你想发多快都可以
比如我们熟知的歇斯底里
可以通过参数调整发送速率
所以运营商一般都不待见
会针对UDP做QoS
线路好的话还没问题
线路差的话一拥堵就优先把UDP干掉
导致疯狂丢包
所以原生UDP不适合线路差的VPS
另一方面是出于安全考虑
假设SS加了tls的plugin插件
UDP的数据并没有被特殊处理
还是按原生UDP的方式发送
出于以上原因
给SS节点加上了UoT的功能
如果要开启这个功能的话
服务端的节点搭建
需要使用指定的内核
不过UoT的缺点也很明显
相当于UDP完全变成了TCP的行为
传输数据前需要先经过3次握手建立连接
中途出现了丢包需要重新补发
不适合对延迟敏感的使用场景
比如即时对战类的游戏
如果你的线路好不会频繁丢包的话
UoT和原生UDP的差距也就没那么大
总结就是如果你对延迟和丢包很敏感
那就要买好的线路
这样的话用原生UDP或者UoT都可以
如果线路差
觉得UDP能用就行
那最好是用UoT
还能套CDN
如果说线路很差又对UDP有要求
底层传输可以使用KCP或者udpspeeder
这种有加速效果的协议
其本质是通过调整发包速率
配合冗余发包来降低延迟和丢包
很容易被运营商QoS
可以配合fakeTCP
将UDP伪装成TCP的流量欺骗运营商
但是国道再怎么加塞
还是解决不了拥堵的事实
真正要有良好的游戏体验
还是直接上高速公路吧
对游戏党而言
直接购买游戏加速器是一个不错的选择
如果你有自己搭建的需求
选择一条好的线路很关键
比如CN2 GIA
这是个人用户能买到的最好线路了
价格也很贵
不过自己搭建的话没有使用人数上限
更适合与朋友合租一起分摊
我会将搬瓦工的美国 日本 香港CN2 GIA
线路的VPS购买链接
放在视频下方的说明栏
有需要的朋友可以进去看看
这是参考价格
他家支持购买后30天内不满意
可以申请全额退款
另外再补充一点
直接使用socks5代理并不一定会被封
只有当你访问黑名单网站才会被阻断
所以如果你真的需要使用节点打游戏
直接使用x-ui搭建一个socks5代理
专门用来打游戏
并且一定要确保
不会用这个节点访问黑名单网站
相当于和防火墙玩明牌
每个数据包中都充满了善意
我这有个朋友
用站群服务器搭建了200多个socks5节点
他就只用来代理游戏
至于你搭建会不会被封
我不敢给大家保证
请自行测试
也欢迎大家在评论区反馈
而对于游戏而言
又不得不提到P2P联机
本来这个也要很大篇幅才能讲明白
本期由于时间关系
没有办法详细探讨
UDP的各种穿透行为
只能简单的给大家讲一下
以后有机会再细说
目前游戏的通讯种类主要分为
中心服务器和P2P联机
通过UDP传输
我们平时玩的网游基本都是中心服务器
玩家直接连接中心服务器进行通信
只要UDP能通就能玩
没什么好说的
而P2P连接是peer to peer的点对点通信
不经过中心服务器
也就是玩家之间直接相互传输数据
PS switch Xbox等
平台的主机游戏用这种方式比较多
还有BT下载也是用这种方式
要想实现P2P通信
玩家之间需要先知道对方的公网IP
这里就需要使用我们一开始提到的
stun服务器
它是协助玩家之间进行UDP穿透的
也叫UDP打洞
更宽泛的叫法是NAT穿透
不过NAT穿透也包括了TCP穿透
所以还是叫UDP穿透更严谨一点
WebRTC也是点对点通信
所以用到了stun服务器
这个系列我每次开头都说
创建一个最常见的家庭网络环境
但其实并不是最常见的
因为大部分用户通过PPPoE拨号
获取到的并不是公网IP
而是运营商分配的内网IP
俗称大内网
而访问互联网
肯定不能通过内网IP访问
所以需要通过NAT转换为公网IP
关于NAT转换
我在节点搭建系列第一节详细介绍过了
负责拨号的路由器会进行一次NAT转换
如果拨号获取到的是公网IP
就可以通过修改路由器NAT的
映射行为和过滤行为
实现fullcone
也叫全锥（完全锥形）
在游戏中叫做NAT开放 或者NAT1 或者NAT A
这种对于P2P而言
是最容易实现UDP打洞的
从而匹配到更多的游戏玩家
遗憾的是由于IPV4地址的枯竭
很多人家里都没有公网IP
拨号获取到的是运营商分配的内网IP
运营商收到你的数据后
还要给你做一次NAT
将其转换为公网IP
你无法修改运营商路由器的NAT行为
而运营商的NAT
行为一般是最严格的对称NAT
很难打洞成功
一般是通过UDP中继来解决
而对于我们而言
天然的就有了一台UDP中继服务器
也就是我们的节点服务器
由于节点服务器拥有公网IP
要实现fullcone很容易
我们只需要把UDP数据交给节点代理即可
通过客户端和服务端的配合实现fullcone
目前fullcone支持最好的是xray内核
所有支持UDP入站的协议都能实现fullcone
其实sing-box内核支持的更全
但是周边的配套设施还没有跟上
上手的话比较困难
感兴趣的朋友可以自行研究
服务端可以使用基于xray内核的
x-ui搭建 就按正常的流程搭建即可
由于fullcone的特性
其他玩家需要能直接访问到你的端口
xray在中继UDP的时候
会随机选择一个高位端口进行对外访问
所以VPS需要开放1024-65535的UDP端口
你也可以直接把防火墙关了
估计也没啥重要的东西
这些基本的操作就不演示了
以前都讲过
网上也有很多教程
客户端也建议使用xray
因为vmess和vless的fullcone
在xray中是通过XUDP实现的
如果客户端不是使用xray
vmess和vless可能无法实现fullcone
可以通过NATtypetester
这个工具来检测你当前的NAT类型
下载地址我会放在视频下方的说明栏
切换到rfc3489的标准
先来测试没有任何代理我本地网络的NAT行为
可以看到类型为symmetric
也就是对称NAT
这是最严格的NAT类型
P2P基本通不了
这里显示了我对外访问的公网IP
你可以在路由器的PPPOE拨号界面
查看运营商给你分配的IP
如果和这里检测出来的IP不同
说明你家没有公网IP
我这里也没有
所以需要通过UDP中继来解决
开启Clash的Tun模式
让其接管系统的全局流量
先过滤UDP的日志
此时再来进行测试
日志显示走直连了
并且NAT类型变成了UDPblocked
说明UDP没通
不过直连的话
应该和刚才测试的结果一样
是对称NAT
有时网络不稳定需要多试几次
可以看到香港1的节点没有UDP的标识
说明没有开启UDP代理
所以走了直连
切换到台湾节点
再来测试一下
可以看到还是显示直连的公网IP
说明没有走代理
因为刚才的UDP连接还没有断开
进入connections面板
点击close all关闭所有连接
回到UDP日志
再来测试
可以看到返回了fullcone
数据交给了台湾节点
公网IP也变成了节点的IP
再来测试一下vmess节点
记得要先断开UDP连接
可以看到发给了美国的vmess节点
和刚才一样显示UDPblocked
可以多测试几次
如果你测试很多次都不行的话
可能是节点服务器没有开启UDP代理
经过多次测试
可以看到这个节点不支持fullcone
也可能是客户端的问题
换成v2rayN试试
v2rayN当前选中的是同一个美国节点
由于我这个版本的v2rayN
没有Tun功能
可以给测试软件添加一个socks5代理
端口填写V2rayN监听的10808
再来测试一下
记得要把clash的Tun模式关掉
不然就成了链式代理了
重新测试
可以看到和clash一样提示不支持
因为现在我们并没有使用xray内核
而是v2ray的内核
双击编辑节点
把这个节点的内核改成xray
之后这个节点就会使用xray内核了
此时再来测试
可以看到实现了fullcone
切换到trojan再试试
节点如果不稳定的话
需要多测试几次才有正确的结果
如果将这个trojan节点改成v2ray内核
再来测试
就会变成对称NAT
我当前使用的v2ray版本是4.44
v2ray5.0以下的版本是不支持fullcone的
xray的话使用1.3以上的版本即可
这就是关于P2P联机实现fullcone的方法
最后还有一个比较隐蔽的问题
单独拎出来再说说
目前主流的浏览器都支持HTTP 3
很多网站也开启了HTTP3访问
比如YouTube Bilibili
HTTP3基于QUIC协议
而QUIC是基于UDP的
在没有配置代理的情况下
我们第一次访问Bilibili的时候
会使用基于TCP的HTTP2发起访问
Bilibili返回网页的同时告诉浏览器
网站支持HTTP3
可以使用HTTP3访问
于是第二次访问
浏览器就会发起HTTP3的请求
也就是基于UDP的QUIC协议
如果浏览器配置了系统代理
此时再访问Bilibili
刚开始我们也讲过
浏览器不会代理UDP的请求
当浏览器配置了系统代理
会直接关闭QUIC功能
转而使用基于TCP的HTTP2访问网站
但是开启透明代理后就不一样了
浏览器没有配置系统代理
clash使用Tun模式接管系统全局流量
访问YouTube会使用基于UDP的QUIC协议
数据被路由到clash
在DNS分流篇中我们讲过
clash目前处理UDP域名的行为
是redir-host的模式
会发起DNS请求获取真实的ip地址
如果使用了明文DNS请求
则不仅存在DNS泄露
还会存在DNS污染
如果节点服务器没有开启上期v2ray中讲的
流量嗅探功能
由于IP被污染了
会出现无法访问的情况
即使开起来流量嗅探可以正常访问
但是QUIC使用的是UDP
如果你的线路不好
使用SS的原生UDP会卡到怀疑人生
而使用vmess这种UoT传输quic
也会对性能有极大的影响
掉速严重
目前普遍的做法是
在DNS分流篇中讲的
直接禁用浏览器的QUIC功能
或者屏蔽掉443端口的UDP数据
等同于屏蔽了QUIC协议
会回退到HTTP2访问
不过屏蔽端口的方式
还是会先发起DNS请求
导致DNS泄露
所以还是建议直接通过禁用浏览器的QUIC功能解决
也可以不用透明代理模式
直接使用系统代理