REALITY在不同运营商网络下表现不一

[iKira]

今天下午测试过，移动网络下是可以正常使用的。但是今晚在电信网络下测试发现就不能用了，配置没做过任何改动。 表现出的差异：

1. 移动网络下：VISION+REALITY+TCP代理正常，可以回落网站（偷自己）
2. 电信网络下：VISION+REALITY+TCP代理联不通，并输出了下面的日志，可以回落网站（偷自己）
3. 移动+电信网络下：Trojan+TLS+TCP代理正常，并可以回落伪装网站

@RPRX 麻烦帮看看问题出在哪，REALITY刚出来，不太清楚运营商搞出什么限制了。

Windows xray-core 输出的日志

Xray 1.8.0 (Xray, Penetrates Everything.) Custom (go1.20.2 windows/amd64)
A unified platform for anti-censorship.
2023/03/10 21:11:31 [Info] infra/conf/serial: Reading config: config.json
REALITY localAddr: 10.0.0.20:12089   DialTLSContext
REALITY localAddr: 10.0.0.20:12090   DialTLSContext
REALITY localAddr: 10.0.0.20:12092   DialTLSContext
REALITY localAddr: 10.0.0.20:12093   DialTLSContext
REALITY localAddr: 10.0.0.20:12094   DialTLSContext
REALITY localAddr: 10.0.0.20:12095   DialTLSContext
REALITY localAddr: 10.0.0.20:12096   DialTLSContext
REALITY localAddr: 10.0.0.20:12097   DialTLSContext
REALITY localAddr: 10.0.0.20:12098   DialTLSContext
REALITY localAddr: 10.0.0.20:12099   DialTLSContext
REALITY localAddr: 10.0.0.20:12100   DialTLSContext
REALITY localAddr: 10.0.0.20:12102   DialTLSContext
REALITY localAddr: 10.0.0.20:12103   DialTLSContext
REALITY localAddr: 10.0.0.20:12104   DialTLSContext
REALITY localAddr: 10.0.0.20:12106   DialTLSContext
REALITY localAddr: 10.0.0.20:12107   DialTLSContext
REALITY localAddr: 10.0.0.20:12109   DialTLSContext
REALITY localAddr: 10.0.0.20:12108   DialTLSContext
REALITY localAddr: 10.0.0.20:12111   DialTLSContext
REALITY localAddr: 10.0.0.20:12113   DialTLSContext

服务端配置：

{
    "listen": "/dev/shm/xray8080.socket",
    "port": 8080,
    "protocol": "vless",
    "settings": {
        "clients": [
            {
                "id": "",
                "flow": "xtls-rprx-vision",
            }
        ],
        "decryption": "none"
    },
    "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
            "show": false,
            "dest": "/dev/shm/realhttps.socket",
            "xver": 0,
            "serverNames": [
                "example.com"
            ],
            "privateKey": "",
            "minClientVer": "",
            "maxClientVer": "",
            "maxTimeDiff": 6000,
            "shortIds": [
                "",
                "0123456789abcdef"
            ]
        }
    }
}

客户端配置：

"outbounds": [
    {
        "protocol": "vless",
        "settings": {
            "vnext": [
                {
                    "address": "IP",
                    "port": 443,
                    "users": [
                        {
                            "id": "",
                            "encryption": "none",
                            "flow": "xtls-rprx-vision",
                        }
                    ]
                }
            ]
        },
        "streamSettings": {
            "network": "tcp",
            "security": "reality",
            "realitySettings": {
                "show": false,
                "fingerprint": "chrome",
                "serverName": "example.com",
                "publicKey": "",
                "shortId": "",
                "spiderX": ""
            }
        },
        "tag": "proxy"
    }
]

Nginx nginx.conf配置：

stream {
    map $ssl_preread_server_name $name {
        example.com xray8080;
    }
    upstream xray8080 {
        server unix:/dev/shm/xray8080.socket;
    }

    server {
        listen 443 reuseport;
        listen [::]:443 reuseport;
        proxy_pass $name;
        ssl_preread on;
    }
}

Nginx域名.conf配置：

server {
    listen 0.0.0.0:80;
    listen [::]:80;
    listen unix:/dev/shm/realhttps.socket ssl http2;
    if ($scheme = http) {return 301 https://example.com$request_uri;}
    ssl_certificate /path/ssl.pem;
    ssl_certificate_key /path/ssl.key;
    ssl_protocols TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security "max-age=63072000" always;
    server_name example.com;
    index index.html index.htm index.php;
    root /home/www/example.com;
    charset utf-8;
    location / {
        try_files $uri $uri/ /index.php?$args;
        if (-d $request_filename) {
            rewrite ^/(.*)([^/])$ http://$host/$1$2/ permanent;
        }
    }
    include enable-php-pathinfo.conf;
    access_log /home/wwwlogs/example.com.log;
}

[chika0801]

我觉得不是xray配置这方面的问题。你要使用好回程线路的VPS，你用的什么VPS你没说。

至于你说的第2条为什么电信在这VPS就不通，真不好猜。

[iKira]

我觉得不是xray配置这方面的问题。你要使用好回程线路的VPS，你用的什么VPS你没说。

至于你说的第2条为什么电信在这VPS就不通，真不好猜。

两台香港CN2，一台美国小鸡。 其中一台香港CN2常用，另外剩余两台备用。这三台都试过，REALITY全都联不通…… 就怕是 #1767 这种情况，运营商精准拉黑。问题是我没怎么大量使用，被拉黑不合理

[xianren78]

我觉得不是xray配置这方面的问题。你要使用好回程线路的VPS，你用的什么VPS你没说。 至于你说的第2条为什么电信在这VPS就不通，真不好猜。

两台香港CN2，一台美国小鸡。 其中一台香港CN2常用，另外剩余两台备用。这三台都试过，REALITY全都联不通…… 就怕是 #1767 这种情况，运营商精准拉黑。问题是我没怎么大量使用，被拉黑不合理

出这个问题的基本上都是电信，我那个被拉黑的韩国甲骨文IP两年没用过，你敢信

[iKira]

我觉得不是xray配置这方面的问题。你要使用好回程线路的VPS，你用的什么VPS你没说。 至于你说的第2条为什么电信在这VPS就不通，真不好猜。

两台香港CN2，一台美国小鸡。 其中一台香港CN2常用，另外剩余两台备用。这三台都试过，REALITY全都联不通…… 就怕是 #1767 这种情况，运营商精准拉黑。问题是我没怎么大量使用，被拉黑不合理

出这个问题的基本上都是电信，我那个被拉黑的韩国甲骨文IP两年没用过，你敢信

问题是 Trojan+TLS+TCP/VLESS+XTLS+TCP 这种老组合反而能用，电信真要这么搞的话就过于奇葩了

[o0HalfLife0o]

我也是电信网络，gcp新加坡台湾，reality套的addons.mozilla.org，从测试到现在预发布一直都正常，唯一一次出问题是前几天我套了一个国内网站，跑了1，2小时被sni封锁了，但是换回addons.mozilla.org后立刻就好了

[xianren78]

我觉得不是xray配置这方面的问题。你要使用好回程线路的VPS，你用的什么VPS你没说。 至于你说的第2条为什么电信在这VPS就不通，真不好猜。

两台香港CN2，一台美国小鸡。 其中一台香港CN2常用，另外剩余两台备用。这三台都试过，REALITY全都联不通…… 就怕是 #1767 这种情况，运营商精准拉黑。问题是我没怎么大量使用，被拉黑不合理

出这个问题的基本上都是电信，我那个被拉黑的韩国甲骨文IP两年没用过，你敢信

问题是 Trojan+TLS+TCP/VLESS+XTLS+TCP 这种老组合反而能用，电信真要这么搞的话就过于奇葩了

emmm，我的那个韩国IP偷自己也不行。我发现如果没有先偷别人被阻拦，上来就偷自己是没问题的。

[o0HalfLife0o]

我发现今天出现问题的似乎都和偷自己有关，有没有想过会不会是你们后端没设置好

[o0HalfLife0o]

如果不确定，或者一时没有测试的网站，可以试试我用的addons.mozilla.org或者learn.microsoft.com

[iKira]

我发现今天出现问题的似乎都和偷自己有关，有没有想过会不会是你们后端没设置好

我能确定跟官方模板不同的点就有两个： 1、我用了unix domain socket来回落 2、偷自己

第2点，偷自己刚刚试了其他域名，还是联不通…… 我再试试用正常端口回落看看吧

[iKira]

如果不确定，或者一时没有测试的网站，可以试试我用的addons.mozilla.org或者learn.microsoft.com

没辙了，用正常端口回落也不行 :(

[xianren78]

我测试我的韩国甲骨文IP，我称之为被CDN管理的一个两年未用的无辜IP，补充修正一下: 1，开始用Reality偷符合要求第三方网站，被阻断3分钟。再次换另外的第三方网站，依然阻断。 2，此时紧接着测试偷自己，注意紧接着测试，偷自己也会被阻断。哪怕只用用浏览器访问一下https://mydomain.dom 都会被阻断。我猜测此时用trojan也不行。 3，扔着不管，处于偷自己的状态但不使用，隔一段时间，我是隔了一两天再次测试偷自己成功。我猜测这时候用trojan也是OK的。

[moranno]

我觉得不是xray配置这方面的问题。你要使用好回程线路的VPS，你用的什么VPS你没说。 至于你说的第2条为什么电信在这VPS就不通，真不好猜。

两台香港CN2，一台美国小鸡。 其中一台香港CN2常用，另外剩余两台备用。这三台都试过，REALITY全都联不通…… 就怕是 #1767 这种情况，运营商精准拉黑。问题是我没怎么大量使用，被拉黑不合理

就算是精准拉黑，也无法解释为何trojan/vless能正常使用，而Reallity不行。这是让我最疑惑的点。

[GreatMichaelLee]

我的一个vultr的小鸡，昨天试了1.8，无论是在电信线路还是移动线路下{我家两条宽带}，每隔两三分钟，reality就联不通了，{猜测就是你们说的sni阻断}，过一会重启一下xray就好了{有时候不重启放久一点也能自动好}，切换回xtls vision持续使用没任何问题，我感觉还是这个reality机制哪里还实现的有问题或不完善，能被墙发现探测到，当然也不排除是vultr的ip被针对和定点监控了，但不太好理解的是xtls vision没任何问题。

[iKira]

刚怀疑是不是软路由某个设置不当导致的，测试了电信的蜂窝网络、家宽，表现一样，REALITY不通，回落正常。同一端口下，上述老组合反而能正常用 :(

[iKira]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

[yuhan6665]

问一下 你们 dest 配置的目标是？换一个试试？

[KevinMX]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

机场多用中转线路甚至专线，国内段多数情况下根本不鸟你用什么。这也是现在还有人在用 SSR 这种东西的原因。

[GreatMichaelLee]

我用的www.ebay.com,还有之前别人那个日本的啥网站，都一样，用几分钟，over.过会就恢复

[iKira]

所以问题来了，有实力的机场，直接搞专线或中转，根本没有担心被端的必要，REALITY也可以不管机场这些毛病。 反而是自己搭建的人会深受这个问题影响，而REALITY推出的目的就是要解决这类问题，绕回来了……

[GreatMichaelLee]

另外我这里对配置有个疑问，ServerName和dest要配成一样吗？dest是回落的，那ServerName配什么？模板里为何是一样？如何是一个好的合理的配置？

[moranno]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

请问“临时可信证书”是哪一步？另外用非443端口也被阻断。

[bcegkmqs23]

另外我这里对配置有个疑问，ServerName和dest要配成一样吗？dest是回落的，那ServerName配什么？模板里为何是一样？如何是一个好的合理的配置？

我的理解是：dest用于指示偷什么站的证书，ServerName是通信中的SNI（服务端设定允许的范围，客户端设定请求时进行的SNI）。一般来说SNI需符合证书的域名范围，可用xray tls ping工具查看。

[jiuqi9997]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

用curl请求测试 会不会触发阻断？

[iKira]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

用curl请求测试 会不会触发阻断？

curl 80端口

<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>

curl 443端口

curl: (52) Empty reply from server

[iKira]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

请问“临时可信证书”是哪一步？另外用非443端口也被阻断。

看这里页面底部的说明： https://github.com/XTLS/REALITY

[jiuqi9997]

进行以下测试进一步确定问题：

1. WEB服务器监听443端口，用curl测试
2. XRAY监听443端口，同上
3. XRAY监听443端口，用代理客户端连接

分别记录阻断情况，不同测试之间需更换本地ip

[moranno]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

请问“临时可信证书”是哪一步？另外用非443端口也被阻断。

看这里页面底部的说明： https://github.com/XTLS/REALITY

有点不解的是似乎reallity才有“临时可信证书”这一步，而shadowtls似乎是直接偷目标网站证书，为啥也产生了一样的阻断呢？

[iKira]

又继续折腾了下，基本搞定了，感谢楼上各位参与帮助，总结一下：

1、电信的网络有玄学（包括家宽、蜂窝网络），极端情况看命，实在不行换超级贵的线路，保证能行。

2、最好按照官方模板要求，剔除所有旧版XTLS遗留下来的所有回落配置，只保留REALITY，避免其他协议（或组合）被探测到。我刚刚把所有无关回落配置剔除，测试了下REALITY就通了，不过又间歇性被阻断了几次，半小时后基本就没怎么断过。可能回落到过时的协议（或组合）也会被土啬探测到。

3、更换端口，对比验证下是否当前端口被阻断了。如果是，无解，默念运营商草泥马。

4、客户端配置文件，这一点我自己疏忽了。每个人用的代理客户端不一样，客户端配置文件不严格按小作文撸也会有影响。我因为分流维护方便，长期在用clash-meta，xray/v2ray的配置文件挺长时间没关注，这次因为要手撸REALITY配置文件，才发现routing这部分写不好也会有影响（我是影响到页面加载速度，还没到加载不了的程度）。

5、撸REALITY配置文件小小总结（仅基于我自己的配置方式）：

• dest支持unix domain socket，也支持本地端口（默认连接127.0.0.1）、网站域名
• 要”偷自己“时，dest可以填本地端口，或unix domain socket（回落的网站要满足h2、TLSv1.3要求）
• 要”偷别人“时，dest可以填目标网站的域名（域名要满足h2、TLSv1.3要求）
• REALITY也支持Nginx前置，配置stream通过SNI分流
• shortId，连不通时先留空，不要瞎折腾，验证能连通了再加ID
• spiderX，必须是真实路径

[RPRX]

与 VLESS 回落功能无关，我看了下群，都什么理解啊，主动探测连 REALITY 那关都过不去，还轮得到 VLESS 回落？

用了 REALITY，VLESS 的回落就不是给你回落到网站用的，是给 Vision 与 H2 / gRPC 同端口共存用的。

[xianren78]

与 VLESS 回落功能无关，我看了下群，都什么理解啊，主动探测连 REALITY 那关都过不去，还轮得到 VLESS 回落？

用了 REALITY，VLESS 的回落就不是给你回落到网站用的，是给 Vision 与 H2 / gRPC 同端口共存用的。

详细说说，这俩怎么同端口共存

[iKira]

与 VLESS 回落功能无关，我看了下群，都什么理解啊，主动探测连 REALITY 那关都过不去，还轮得到 VLESS 回落？

用了 REALITY，VLESS 的回落就不是给你回落到网站用的，是给 Vision 与 H2 / gRPC 同端口共存用的。

这么一说就理解了，我已经把旧的回落配置全删了，只保留REALITY。gRPC我这没法用，电信网络还是会淦gRPC，只能TCP。

[RPRX]

REALITY 是 TLSv1.3，VLESS 有回落很正常，默认回落到 H2C 或 gRPC 就能共存了，但这俩协议不一定不封端口，风险自负

其实我有个猜想，就是对于白名单网站，可能现在 GFW 并不分析流量模型，所以测不出来封不封端口

[simplerick-simplefun]

@RPRX 请问大佬：直接用reality+grpc或reality+h2，对比reality+vision+tcp的安全性（不被封）如何？是前后一样，还是后者更安全？

[chika0801]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

类似现象，我是联通，3个欧洲国际线路回程机，reality用的域名是动漫.jp，一些记录 https://github.com/XTLS/Xray-core/discussions/1772

[chika0801]

@RPRX 请问大佬：直接用reality+grpc或reality+h2，对比reality+vision+tcp的安全性（不被封）如何？是前后一样，还是后者更安全？

建议关注 xray tg 频道或群

现在可以直接配置 REALITY H2 服务端，实测 N 个请求只开一条 H2，延迟超低，纵享丝滑。"flow" 为空，"network" 改为 "h2" 即可。

另一种方式是配置 REALITY VLESS 回落至 H2C，它可以与 Vision 共存，但暂不建议。H2 自带 MUX，理论上也可以减轻 TLS in TLS 特征，是否有效仍需实测。但若目标域名在白名单内，可能测不出区别。现在可以直接配置 REALITY H2 服务端，实测 N 个请求只开一条 H2，延迟超低，纵享丝滑。"flow" 为空，"network" 改为 "h2" 即可。

另一种方式是配置 REALITY VLESS 回落至 H2C，它可以与 Vision 共存，但暂不建议。H2 自带 MUX，理论上也可以减轻 TLS in TLS 特征，是否有效仍需实测。但若目标域名在白名单内，可能测不出区别。

reality+vision+tcp 使用提醒见 https://github.com/chika0801/Xray-examples

[iKira]

REALITY 是 TLSv1.3，VLESS 有回落很正常，默认回落到 H2C 或 gRPC 就能共存了，~但这俩协议不一定不封端口，风险自负~

~其实我有个猜想，就是对于白名单网站，可能现在 GFW 并不分析流量模型，所以测不出来封不封端口~

提个功能建议，能否考虑下让 RoutingObject 模块支持调用远程文件来加载IP、域名黑白名单，类似这样：

"routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
        {
            "domain": [
                "url:https://xxx.com/path/gfw.txt",
                "url:https://xxx.com/path/google.txt",
                "url:https://xxx.com/path/telegram.txt",
                "url:https://xxx.com/path/netflix.txt"
            ],
            "path": ./rules //规则文件下载到core所在目录的rules文件夹内，无rules文件夹则自动创建
            "inboundTag": ["inbound-socks5"],
            "outboundTag": "outbound-default-proxy"
        },
        {
            "ip": [
                "url:https://xxx.com/path/!cnip.txt"
            ],
            "path": ./rules
            "inboundTag": ["inbound-socks5"],
            "outboundTag": "outbound-default-proxy"
        },
        {
            "domain": [
                "url:https://xxx.com/path/cndomain.txt"
            ],
            "path": ./rules
            "inboundTag": ["inbound-socks5"],
            "outboundTag": "outbound-direct"
        },
        {
            "ip": [
                "url:https://xxx.com/path/cnip.txt"
            ],
            "path": ./rules
            "inboundTag": ["inbound-socks5"],
            "outboundTag": "outbound-direct"
        }
    ]
}

远程文件则按 RoutingObject - domain 的规则进行编写，如：

- sina.com
- regexp:\\.goo.*\\.com$
- domain:xray.com
- full:xray.com

这样我就可以复用 https://github.com/blackmatrix7/ios_rule_script 的规则文件，在vps上写个sh脚本，每天自动转换规则为xray的格式并生成新的txt文件，放到我自己的web服务器上提供url给xray调用。

我当前的用法是设定时任务，每天自动更新一次GEOIP和GEOSITE文件，并重启一次xray-core。现在这么用不利于我自由添加黑名单域名或IP，如果能远程调用的话，我可以自由添加域名或IP进去。

[cross-hello]

You can write a tcp program to listen port and accept modified RoutingObject rules. Then modify ray configuration according to content above. Restart ray after.

[cross-hello]

You could get a example of TCP content exchange by https://github.com/cross-hello/Linux-Remote-Command-Execute

[iKira]

You could get a example of TCP content exchange by https://github.com/cross-hello/Linux-Remote-Command-Execute

thanks :)

[cross-hello]

That program was written near graduation. Now must could write better, but indeed there is more important thing to do, like learn violin, neural network, mathematics or physical.

So bugs inside just ignore is OK. [Shy]

Mar 11, 2023 20:56:27 iKira @.***>:

You could get a example of TCP content exchange by https://github.com/cross-hello/Linux-Remote-Command-Execute

thanks :)

— Reply to this email directly, view it on GitHub[https://github.com/XTLS/Xray-core/issues/1769#issuecomment-1464906643], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYHS6XJUKK3E5HD2ZO3W3RY7XANCNFSM6AAAAAAVWO6SXQ]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AKGBAYCGPDYQJN4TINXTK3LW3RY7XA5CNFSM6AAAAAAVWO6SXSWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSXKCZZG.gif]

[chika0801]

找到原因了，电信针对443端口REALITY阻断，应该就是”临时可信证书“握手这一步被电信端了。 现在唯一好奇的是电信是怎么端掉”临时可信证书“的，以及为什么只搞REALITY，老组合反而不搞，难道因为那些机场用的都是更老的组合，Trojan+TLS+TCP/VLESS+XTLS+TCP 这种组合用的人少反而没必要端？

类似现象，我是联通，3个欧洲国际线路回程机，reality用的域名是动漫.jp，一些记录 #1772

在群里有个群友也在反馈类似（是联通到软银好回程线路），印象中前7天iss上表达类似的或群里咨询也有不少，记得是表达的问遇到断流怎样解决。也有群友用监控tcp ping icmp ping的遇到icmp正常 tcp ping超时的例子（他说是nginx vmess grpc warp出）。暂不好猜原因来自哪方面。

[cheneyxx]

@chika0801 老哥 reality偷域名是不是不要偷有国内cdn的 比如www.amd.com 这种

[chika0801]

@chika0801 老哥 reality偷域名是不是不要偷有国内cdn的 比如www.amd.com 这种

没有这个要求吧。之前说的是比如www.amd.com有用CF的CDN，就容易被人扫到，你的VPS成为别人眼中的中转机。当然这问题你可以用比如NGINX的SNI分流来屏蔽（解决）。 我也没注意过其他人在群里有不有讨论过说比如www.amd.com要不要在国内有CDN。主要是我自己用的VPS都是些对我来说贵些的，IP干净些的，和我是主要用的几个VPS买的自己的域名搭的偷自己形式。

我以前测试过一些10刀年付价格的机，DEST填比如洛杉矶哪个大学博物馆的网址，给别人用（测试）后来测试的人给我说上不起了，类似的遇到后换个端口会通。只是通后没常用再测（无后续对比测试了），这个经验。

简单说我自己用的VPS（数量不为1），都是有回国线路优化的商家的机，价位也至少不是10几刀国际线路的。买个域名，申请个SSL证书，用REALITY的偷自己形式，和别人一些人（朋友）共用，到现在没遇到被封端口，反应有什么莫名不稳等的现象。