在还没releases的时候就已经拿国内的服务器试过了，效果还不错，就是试国内哪个网站支持tls1.3试了半天，最终用了www.126.com，主动探测的表现完全就是4层代理，无论目标网站是否支持tls1.3都会4层代理，但只有在目标网站支持tls1.3的情况下才能正常进行reality通讯，reality我只看重一点就是换服务器部署很简单，不用弄证书了，直接装完Xray配置一上传再弄下防火墙就完事了，签证书在我看来是相当麻烦的事情。
另外有个必然会出现的特征就是域名和ip是不匹配的，也就是无论哪里的dns，目标网站都是不可能解析到你的服务器的，尤其是国内访问国外的时候解析结果基本没什么变化，有的isp的ip也根本不可能是目标网站可能用得，但是域名和ip不匹配的问题并不大，我之前的服务器也从来没有用sni指示的域名解析到服务器上面去，我还会用同一个域名连到不同国家的服务器，并没有被墙（其实我至今没有被墙过任何一个端口或ip，多大的流量都没关系，我寻思1个月换一次ip也不是什么很频繁的频率，而且用得都是clash premium），所以虽然这个特征明显但是似乎并没有部署相关措施或者说应该会根据更多的特征去识别。
官方用得是VLESS+vision，我对于加密比较执着喜欢vmess，至少有2层加密，只要不被解密就行，就算gfw真的保存了所有的数据，并且在大型量子计算机完善后尝试破解，不对称加密和对称加密破解使用的算法是不同的，对称加密的破解在量子计算机面前依旧非常困难，gfw的政策向来是监控>阻止，阻止行为是因为无法监控才做出的下策，不太可能把大量时间浪费套娃加密身上，并且应该注意如果用国内中转，我们得假设gfw已经知道了国内服务器数据，最好只做4层或tls层中转，vmess的数据不要在国内解开重新打包，国内那层tls就当没有任何保密性，私钥都是保存在服务器上的，也不要把其他设备使用的uuid放在服务器上，什么时候后量子证书普及我才相信单tls加密是安全的，并不是特别在乎因为tls in tls、级联加密特征这种小问题被封，vmess本身就具有随机填充，在grpc里分析这种时序并不轻松，只要能运行相当长一段时间即可，如果是自己用的话性能损失根本感受不到，而且grpc不能用xtls，我很喜欢grpc的多路复用。
贴一下我的vmess+grpc+reality配置，reality是手写的（希望用x-ui监控流量可以让reality监听别的127.0.0.1的端口，然后x-ui里用dokodemo-doorl转发tcp443到本地的那个端口就好了），80和udp443是用x-ui面板入站里添加的（官方推荐这么做的，而且可以用Xray实现，不然我真懒得弄），虽然streamSettings.network是TCP，我拿www.cloudflare.com稍微测试了一下，浏览器里f12能看到部分请求是h3协议的，然后我的reality和udp443转发到不同的地址，reality先转发到cloudflare cdn地址和目标网站协商出h3，然后udp443转发到www.cloudflare.com提示得是cloudflare的网站，所以这个stream里的tcp并不会影响udp的转发，主要是x-ui里能看到流量，不用x-ui的话streamSettings完全可以删掉，我只是方便看流量，udp443是很重要的主动探测检查（www.microsoft.com没有http3，其他域名会用到），因为reality是不会握手握出h3的，80还有可能是用了我的域名访问到的，如果目标网站不接受未知域名那么udp443有流量必是主动探测或是中间人攻击。
{
"inbounds": [
{
"listen": null,
"port": 443,
"protocol": "vmess",
"settings": {
"clients": [
{
"id": "xxxxxxxxxxxxxxxxxxxxxxxx",
"alterId": 0
}
]
},
"streamSettings": {
"network": "grpc",
"security": "reality",
"realitySettings": {
"show": false,
"dest": "127.0.0.1:9443", //见下方解释
"serverNames": [
"www.microsoft.com"
],
"privateKey": "xxxxxxxxxxxxxxxxxxxxxxxxxxx",
"shortIds": [
"1111111111111111"
]
},
"grpcSettings": {
"serviceName": "xxxxxxxxxxxxxxxxxxxxxx",
"multiMode": false
}
},
"tag": "vmess-Reality",
"sniffing": null
},
{
/*这个是为了转发到目标网站的时候用warp出站，
确保被偷域名的网站不知道服务器真实ip，
reality那个dest怎么测感觉都是直连，
测试方法是用cloudflare把自己ip加入白名单，
然后用waf把某个主机名全部阻止，
我发现一直没有阻止成功，
我也没兴趣找问题，
加一个dokodemo-door问题就解决了*/
"listen": "127.0.0.1",
"port": 9443,
"protocol": "dokodemo-door",
"settings": {
"address": "www.microsoft.com",
"port": 443,
"network": "tcp"
},
"streamSettings": {
"network": "tcp",
"security": "none",
"tcpSettings": {
"header": {
"type": "none"
}
}
},
"tag": "inbound-9443",
"sniffing": {}
},
{
"listen": null,
"port": 443,
"protocol": "dokodemo-door",
"settings": {
"address": "www.microsoft.com",
"port": 443,
"network": "udp"
},
"streamSettings": {
"network": "tcp",
"security": "none",
"tcpSettings": {
"header": {
"type": "none"
}
}
},
"tag": "inbound-443",
"sniffing": {}
},
{
"listen": null,
"port": 80,
"protocol": "dokodemo-door",
"settings": {
"address": "www.microsoft.com",
"port": 80,
"network": "tcp,udp"
},
"streamSettings": {
"network": "tcp",
"security": "none",
"tcpSettings": {
"header": {
"type": "none"
}
}
},
"tag": "inbound-80",
"sniffing": {}
}
],
"outbounds": [
{
"protocol": "wireguard",
//省略warp配置，仅仅只是为了能更容易看懂
"tag": "warp"
}
],
"routing": {
"rules": [
{
"inboundTag": [
/*可以使用warp出站使被偷域名的网站不知道服务器的真实ip，
并且有warp+的话可以加快访问速度*/
"inbound-9443",
"inbound-443",
"inbound-80"
],
"outboundTag": "warp",
"type": "field"
}
]
}
}我用得是warp出站，不过warp的ip毕竟连城市都和服务器在同一个地方，如果为了更安全的偷域名可以用Tor，反正偷tls行为也浪费不了多少时间，很长的一段时间才会偷一次（注意这是grpc自带多路复用的特性，用tcp-xtls走tor将会奇慢），伪装只要有反应就行了，至于有多慢那不是我该关心的，我只关心不要把我的服务器ip被人当攻击ip就行了，在这个配置下，所有对我服务器80和443的流量都会传到目标网站，我没有办法去分辨攻击流量，有心人会拿我的服务器当跳板攻击微软，为了避免可能存在的责任，tor是最好的选择，tor的攻击流量很常见，而且无法溯源。
{
"outbounds": [
{
"tag": "proxy",
"protocol": "vmess",
"settings": {
"vnext": [
{
"address": "1.1.1.1",
"port": 443,
"users": [
{
"id": "xxxxxxxxxxxxxxxxxxxxxx",
"alterId": 0,
"security": "chacha20-poly1305"
}
]
}
]
},
"streamSettings": {
"network": "grpc",
"security": "reality",
"realitySettings": {
"show": false,
"fingerprint": "chrome",
"serverName": "www.microsoft.com",
"publicKey": "xxxxxxxxxxxxxxxxxxxxxx",
"shortId": "1111111111111111"
},
"grpcSettings": {
"serviceName": "xxxxxxxxxxxxxxxxxxxxxx"
}
}
}
]
}