使用了最新的1.8.0，同样发生了和我在shadowtls中遇到一样的阻断情况 #1767

moranno · 2023-03-10T05:33:00Z

xray1.8.0使用的配置方式为：https://github.com/chika0801/Xray-examples/tree/main/VLESS-H2-uTLS-REALITY

发生阻断情况详细描述见这里：ihciah/shadow-tls#78

这里有restls作者的分析：3andne/restls#8

以及这里有类似的情况：#1752

基于我之前观察和分析，我猜测：
是因为我服务器地址填写的是IP，但TLS表演的却是www.bing.com；导致gfw无法获取sni，所以阻断。
如果可以配置sni为TLS链接的www.bing.com，我想可以避免阻断。

RPRX · 2023-03-10T05:45:15Z

首先，你的猜测是错的，SNI 就是 www.bing.com

moranno · 2023-03-10T05:52:32Z

首先，你的猜测是错的，SNI 就是 www.bing.com

有没有啥绕过手段呢？
如果是换冷门IP似乎不是个很好的解决方案，我尝试了几个主流服务商的IP均会发生阻断，冷门地区IP不会发生立即阻断，但似乎gfw能学习，我用shadowtls第一天能正常使用，第二天被阻断。
如果用ss/vmess等加密协议，还能坚持几天...

o0HalfLife0o · 2023-03-10T05:53:12Z

只能说你的配置肯定有问题，我一直是地址写IP，sni写域名，一直都正常的

o0HalfLife0o · 2023-03-10T05:54:54Z

你为啥不把你的服务端和客户端配置完整贴上来呢

RPRX · 2023-03-10T05:58:43Z

其次，有没有一种可能，是你的本地 IP 进运营商的黑名单了，我建议你换个运营商试试

xianren78 · 2023-03-10T05:59:24Z

不是配置问题，是IP问题，这个IP被当成CDN的IP管理了。我有个IP 443端口只要有TLS握手就阻断3分钟。偷自己证书都阻断。

moranno · 2023-03-10T05:59:24Z

你为啥不把你的服务端和客户端配置完整贴上来呢

服务端配置：

{
    "log": {
        "loglevel": "warning"
    },
    "routing": {
        "domainStrategy": "IPIfNonMatch",
        "rules": [
            {
                "type": "field",
                "ip": [
                    "geoip:cn"
                ],
                "outboundTag": "block"
            }
        ]
    },
    "inbounds": [
        {
            "listen": "0.0.0.0",
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "24236d0f-311f-406c-a7a6-c83c2ecd734c", // 必填，执行 xray uuid 生成，或 1-30 字节的字符串
                        "flow": "" // 留空
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "h2",
                "security": "reality",
                "realitySettings": {
                    "show": false, // 选填，若为 true，输出调试信息
                    "dest": "www.lovelive-anime.jp:443", // 目标网站最低标准：国外网站，支持 TLSv1.3 与 H2，域名非跳转用（主域名可能被用于跳转到 www）
                    "xver": 0,
                    "serverNames": [ // 客户端可用的 serverName 列表，暂不支持 * 通配符
                        "lovelive-anime.jp", // 执行 xray tls ping 目标网站网址，填 "Allowed domains" 的值
                        "www.lovelive-anime.jp"
                    ],
                    "privateKey": "Dx42LgET1N-BERWl6sx3BI1f5jIxQVzAVplql68NL1c", // 执行 xray x25519 生成，填 "Private key" 的值
                    "shortIds": [ // 客户端可用的 shortId 列表，可用于区分不同的客户端
                        "", // 若有此项，客户端 shortId 可为空
                        "a1", // 0 到 f，长度为 2 的倍数，长度上限为 16
                        "bc19",
                        "b2da06",
                        "2d940fe6",
                        "b85e293fa1",
                        "4a9f72b5c803",
                        "19f70b462cea5d",
                        "6ba85179e30d4fc2"
                    ]
                }
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        },
        {
            "protocol": "blackhole",
            "tag": "block"
        }
    ],
    "policy": {
        "levels": {
            "0": {
                "handshake": 2,
                "connIdle": 120
            }
        }
    }
}

客户端配置：

{
    "log": {
        "loglevel": "warning"
    },
    "routing": {
        "domainStrategy": "IPIfNonMatch",
        "rules": [
            {
                "type": "field",
                "domain": [
                    "geosite:cn",
                    "geosite:private"
                ],
                "outboundTag": "direct"
            },
            {
                "type": "field",
                "ip": [
                    "geoip:cn",
                    "geoip:private"
                ],
                "outboundTag": "direct"
            }
        ]
    },
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": 10808,
            "protocol": "socks",
            "settings": {
                "udp": true
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            }
        },
        {
            "listen": "127.0.0.1",
            "port": 10809,
            "protocol": "http",
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "150.230.xx.xx", // 服务端的域名或 IP
                        "port": 443,
                        "users": [
                            {
                                "id": "24236d0f-311f-406c-a7a6-c83c2ecd734c", // 与服务端一致
                                "encryption": "none",
                                "flow": "" // 留空
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "h2",
                "security": "reality",
                "realitySettings": {
                    "show": false, // 选填，若为 true，输出调试信息
                    "fingerprint": "chrome", // 必填，使用 uTLS 库模拟客户端 TLS 指纹
                    "serverName": "www.lovelive-anime.jp", // 服务端 serverNames 之一
                    "publicKey": "Z84J2IelR9ch3k8VtlVhhs5ycBUlXA7wHBWcBrjqnAw", // 服务端执行 xray x25519 生成，私钥对应的公钥，填 "Public key" 的值
                    "shortId": "6ba85179e30d4fc2", // 服务端 shortIds 之一
                    "spiderX": "/J3rHoVqdpUCjDTUBrk5k" // 爬虫初始路径与参数，建议每个客户端不同
                }
            },
            "tag": "proxy"
        },
        {
            "protocol": "freedom",
            "tag": "direct"
        },
        {
            "protocol": "blackhole",
            "tag": "block"
        }
    ]
}

o0HalfLife0o · 2023-03-10T06:06:06Z

spiderX应该填对应网站正常路径就行了吧，比如我用addons.mozilla.org，他们网站路径就是从/en-US/firefox/开始，就跟着这么填就是了，其他应该没啥问题，可能真的就是其他人说的IP有问题

moranno · 2023-03-10T06:55:40Z

其次，有没有一种可能，是你的本地 IP 进运营商的黑名单了，我建议你换个运营商试试

本地IP就是正常的电信宽带，每次拨号都会变。

我刚刚用完全相同的网络环境，电信家宽（ip未变）；同一台vps（相同ip，相同端口）用xray 1.8创建了一个trojan tcp tls服务，
使用zerossl申请的免费证书，不跳过证书验证，客户端服务器地址填写域名，可以正常使用，不会发生阻断。

RPRX · 2023-03-10T07:16:39Z

我刚刚用完全相同的网络环境，电信家宽（ip未变）；同一台vps（相同ip，相同端口）用xray 1.8创建了一个trojan tcp tls服务，使用zerossl申请的免费证书，不跳过证书验证，客户端服务器地址填写域名，可以正常使用，不会发生阻断。

你用这个组合，可能在一两天后喜提来自 GFW 的封端口，而不是运营商临时阻断了，建议换 Vision，~~虽然可能已经来不及了~~

moranno · 2023-03-10T07:22:48Z

你用这个组合，可能在一两天后喜提来自 GFW 的封端口，而不是运营商临时阻断了，建议换 Vision，~~虽然可能已经来不及了~~

嗯，封端口是肯定的。我就是说下为啥使用Trojan不会发生阻断？

刚刚试了用vless-tcp-vision，使用了和trojan相同的证书和域名，没有跳过证书验证，配置文件完全按照这个来的：https://github.com/chika0801/Xray-examples/tree/main/VLESS-XTLS-Vision

同样发生了阻断

我并不是挑刺，而是真心想通过我提供的信息找到问题所在...如果方便的话我可以提供远程桌面等环境测试。

o0HalfLife0o · 2023-03-10T07:26:14Z

服务器IP脏了，啥都没用了，要么换IP，要么用ws套CDN缓缓，不过cdn封的也很厉害，也许可以优选一堆CDN IP配合遥测自动切换，或者就是先找个其他的免费服务用用算了

moranno · 2023-03-10T07:28:11Z

服务器IP脏了，啥都没用了，要么换IP，要么用ws套CDN缓缓，不过cdn封的也很厉害，也许可以优选一堆CDN IP配合遥测自动切换，或者就是先找个其他的免费服务用用算了

那为啥trojan不发生阻断呢？
而且我使用相同证书，相同服务器，相同家宽，相同端口，相同域名的情况下，vless也没事
让人很疑惑...

o0HalfLife0o · 2023-03-10T07:33:13Z

我的看法是IP没救了，搁置一段时间也许能恢复，当然我的看法不重要，你想怎么用或者说怎么样可以用就怎么用吧

Nyar233 · 2023-03-10T07:33:45Z

那为啥trojan不发生阻断呢？
而且我使用相同证书，相同服务器，相同家宽，相同端口，相同域名的情况下，vless+vision发生了阻断。
让人很疑惑...

你给的配置不是vision

RPRX · 2023-03-10T07:34:30Z

@moranno 你所描述的”阻断“，看起来像运营商自定的，而不是 GFW 级别的，本来GFW 就是黑箱，运营商的限流策略更是多变

之前你有过这样的描述：

之前用trojan的时候也被sni阻断过，和上面的情况一模一样。

那么你刚刚遇到的情况极大可能是，你先用 Trojan 时，运营商的限流系统还在收集信息，你再用其它时恰好被安排上

RPRX · 2023-03-10T07:50:38Z

你要知道，和 GFW 一样，运营商的限流系统并不是无状态的，而是有数据库，这是常识，要测试，最起码把顺序颠倒几次测几遍

但不会有区别，因为无流控时，VLESS 协议和 Trojan 协议就只有协议头的区别，在运营商的限流系统看来它们就是同一个东西

你的 IP 就是运营商给分配的，即使不同，运营商也知道还是你，我让你先换运营商试试你不试，非要让我们来花时间解决你的运营商对你的帐号的限流问题，要不是上面你甩出个反常识且极具误导性的测试过程及结果，我真的不想浪费时间来回复你

RPRX · 2023-03-10T07:56:59Z

比如说，我是你的运营商，我的系统记录了你 FQ 的黑历史，所以我决定对你向境外的连接实施非常严格的过滤、限流、阻断策略

你被针对了，这怎么解决？除了换运营商，没有任何办法

moranno · 2023-03-10T08:00:45Z

但不会有区别，因为无流控时，VLESS 协议和 Trojan 协议就只有协议头的区别，**在运营商的限流系统看来它们就是同一个东

感谢耐心回复，你说到流控时候，我尝试把服务端和客户端vless配置中的 "flow": "xtls-rprx-vision" 注释了，然后vless也不会阻断了！

再次重申，我用的vless配置完全照搬：https://github.com/chika0801/Xray-examples/tree/main/VLESS-XTLS-Vision
仅仅注释了"flow": "xtls-rprx-vision" 就不会触发阻断。

我没明白流控的作用，所以可能问题还是在流控修改了某些东西？以及reality/shadotls也用了类似的东西？

可能是被针对，不过我这个现象每次修改配置都能精准复现。

RPRX · 2023-03-10T08:06:02Z

说实话由于你的测试过程在我看来不严谨，我很难相信你的测试结果

~~手机开流量，先换个运营商试试很难吗~~

Extreme-Icer · 2023-03-10T08:07:07Z

比如说，我是你的运营商，我的系统记录了你 FQ 的黑历史，所以我决定对你向境外的连接实施非常严格的过滤、限流、阻断策略

你被针对了，这怎么解决？除了换运营商，没有任何办法

R佬别生气不如回复一下我的一个离题的疑问入站代理中的routeonly不需要DNS二次解析仅嗅探说被代理连接指的是客户端连接到xray服务端还是本机其他服务（比如Android开ADGuard 以系统VPN形式存在，V2rayNG仅代理模式）

RPRX · 2023-03-10T08:07:39Z

@moranno 还有，你所说的”注释“，~~不是只在一端注释了吧~~

Wyatt323 · 2023-03-10T08:13:00Z

说实话由于你的测试过程在我看来不严谨，我很难相信你的测试结果

~~手机开流量，先换个运营商试试很难吗~~

大佬，我最近遇到了问题感觉跟他的描述差不多，情况是这样的（搭建的是 vmess+ws+tls+nginx）
3月7日00:00 移动宽带下准时所有自建节点全部连不上，第一时间测了ip和端口都没被封，用手机电信5G测还能用，但是过半小时5G也连不上了
同一天的下午我回到家里测试电信的宽带，也是这个情况，但是这个时候5G又可以连了，这几天下来5G都是时好时坏；与此同时我重新搭建了vmess+ws,vless_ws等不带tls的节点都可以正常使用
同天晚上我换了域名重新搭建这种模式的节点，存活半小时再次连不上

这种我连不上的节点，别人都可以正常用

我知道这个方式可能已经落伍了，但是想问一下这个是什么阻断

moranno · 2023-03-10T08:13:23Z

@moranno 还有，你所说的”注释“，~~不是只在一端注释了吧~~

服务端和客户端都同时注释了，现在已经跑了20分钟所有的持续流量，没有引发阻断。

关于手机热点...我人在国外，用的远程回国内台式机上测试的...所以不太方便改运营商，如果需要我录个视频？

edit: 刚刚我又尝试把"flow": "xtls-rprx-vision" 加了回来，现在不会阻断了....刚刚的vless+vision阻断估计是误报，~~也可能是我后台还运行reallity没关~~

moranno · 2023-03-10T08:38:25Z

然后我又启动了reality服务，尝试链接，立马发生了阻断：

3分钟阻断过后，切换到vless+vision，正常链接，不会阻断：

cross-hello · 2023-03-10T08:38:50Z

@Wyatt323 This is the wireshark traffic capture of VMESS+WS.

Even if you use SSH for a long time will get reset sometimes. So maybe traffic amount and time were recorded.

cross-hello · 2023-03-10T08:50:59Z

If initial connection establish packages were capture by wireshark, it will be possible to figure it explicitly as websockets, instead of general TCP.

RPRX · 2023-03-10T08:53:59Z

@moranno 你是开 SS / VMess 中转机场之类的吧

szouc · 2023-03-10T09:16:09Z

我也有类似现象，另外应该是本地 ip 阻塞，因为在阻塞时间段，我的两台 VPS 同时无法 ssh 链接，尽管我只是用了一台配置了 reality 和 shadowTLS 的 VPS，而且不分平台，测试过 xray 和 sing-box。

moranno · 2023-03-10T09:25:43Z

我也有类似现象，另外应该是本地 ip 阻塞，因为在阻塞时间段，我的两台 VPS 同时无法 ssh 链接，尽管我只是用了一台配置了 reality 和 shadowTLS 的 VPS，而且不分平台，测试过 xray 和 sing-box。

嗯嗯，是本地IP与目的IP的精准阻塞。
现在的问题是，reality/shadowtls的某种实现导致这个精准阻塞的发生？

RPRX · 2023-03-10T09:39:34Z

@moranno

嗯，直到你说人在国外，一听就是开机场。
那么不论是你的国外 IP 还是国内机器，在 GFW 和运营商那里黑历史都爆满了，现在它们决定封掉这些机场，~~实在不行就改行吧。~~

机场的问题很复杂，这里不是给机场提供免费技术支持的地方，我愿意在这里花时间，是为了信息的通畅，不是为了帮机场赚钱。
我在这里写代码、处理问题已经很耗时间了，相当于扔了很多钱，解决你的问题要扔更多的钱，即使你想给我钱我也不会拿。

所以我不会帮你解决这个问题，我建议你自己研究这方面技术，然后像我一样可以自己解决遇到的问题 #1750 (comment)

~~话说回来，现在我自用的 FQ 方式，你们根本想象不到。~~

moranno · 2023-03-10T15:59:30Z

机场的问题很复杂，这里不是给机场提供免费技术支持的地方，我愿意在这里花时间，是为了信息的通畅，不是为了帮机场赚钱。我在这里写代码、处理问题已经很耗时间了，相当于扔了很多钱，解决你的问题要扔更多的钱，即使你想给我钱我也不会拿。

所以我不会帮你解决这个问题，我建议你自己研究这方面技术，然后像我一样可以自己解决遇到的问题 #1750 (comment)

@RPRX
reality这个技术到机场落地还远着呢（现在的用户还在用三五年前的客户端）。
我反馈问题，是对新技术的喜爱，也是希望realliy能走得更好更远。这个问题看来在电信运营商下不是个案：
#1769
我的问题其实就一个：为啥trojan和vless能正常使用？而reallity不行？
都是相同的“高危”ip，vless使用的还是自己的域名。

ps：测试的vless到现在没都阻断。

chika0801 · 2023-03-10T16:01:46Z

他肯定没环境测，或许叫群友（如果能）收集信息或用你提供的信息推测，太难了

RPRX · 2023-03-11T10:40:58Z

@moranno ~~你人在国外开着机场说是对新技术的喜爱，我是很难相信的。~~
#1769 是乌龙，至于你的问题，有没有一种可能，是你配置错了，或选的 dest 不合适，你的环境受限，现在只能多换一些试试。

关于机场，说实话，我对机场落地这类技术，持保留态度。

从去年底乃至这些年的经验来看，很多时候，GFW 的封锁策略优先讲究一个最多人用、最大收益，而不是你协议特征明不明显。
TLS 类一疯狂，指纹和 TLS in TLS 检测就被重点安排上了，反而是小众的 UDP 类没有被针对、还可以用。
要说特征，其实混淆后的 UDP 包一眼假，检测起来比 TLS 类更容易，只是机场已经遍地 TLS 类，而 UDP 类还是自建居多。

那谁会成为靶子就很明显了，这也好理解，假如你是 GFW 的供应商，最后交差个 FQ 封锁率才百分之几的东西，不太合适吧。
肯定先找用的人多的下手，也就是机场喜欢用的那些什么 SS / VMess，什么 Trojan，针对研究，一封一片，效果拔群。

所以

chika0801 · 2023-03-11T11:14:46Z

udp类，建议在cn开obs，是hysteria那边的快速入门里提到的，且它的作者也在它的tg群多次提到是想大家优先用obs,它群的公开信息

首先 UDP 就没连接的概念 所以不存在 shadowsocks 之前那种建立连接以后发几个字节看反应的探测方式
开了 obfs 以后不知道密码构造不出有效的包 无论发什么服务端都不会有反应


默认值确实是 hysteria 这个怎么说呢 当时本来就是希望所有人开 obfs 用的
而且不开 obfs 的话即使 alpn 用 h3，主动探测一下也能发现这并不是 http3 server

RPRX · 2023-03-12T06:11:22Z

开混淆可以暂时解决“没有真正的 h3 server 而露馅”的问题，但是带来了另一个问题，即变成了全随机数，它本身就是更明显的特征

以前对于 SS 这类“全随机数是不是最大的特征”还有过争议，现在已经没有悬念了，GFW 直接封了目标 IP 也不会有什么附带伤害

根据目前的反馈，暂时只有部分地区的 GFW 把该策略应用到了 UDP，且暂时只是封端口，~~但是一旦机场大规模上，就~~

zcluo · 2023-03-12T12:59:22Z

我也有类似现象，另外应该是本地 ip 阻塞，因为在阻塞时间段，我的两台 VPS 同时无法 ssh 链接，尽管我只是用了一台配置了 reality 和 shadowTLS 的 VPS，而且不分平台，测试过 xray 和 sing-box。

我自己的两台机器也出现类似情况SSH上不去了。。

RPRX closed this as not planned Won't fix, can't repro, duplicate, stale Mar 10, 2023

RPRX mentioned this issue Mar 10, 2023

关于sni阻断？尝试使用v2和v3链接，首次链接能通，然后本地ip与服务器ip被阻断3分钟 ihciah/shadow-tls#78

Closed

iKira mentioned this issue Mar 10, 2023

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

Closed

RPRX mentioned this issue Jul 11, 2023

钓鱼 TLS 攻击的可行性 #2317

Closed

使用了最新的1.8.0，同样发生了和我在shadowtls中遇到一样的阻断情况 #1767

使用了最新的1.8.0，同样发生了和我在shadowtls中遇到一样的阻断情况 #1767

Comments

moranno commented Mar 10, 2023 • edited Loading

RPRX commented Mar 10, 2023

moranno commented Mar 10, 2023

o0HalfLife0o commented Mar 10, 2023

o0HalfLife0o commented Mar 10, 2023

RPRX commented Mar 10, 2023

xianren78 commented Mar 10, 2023

moranno commented Mar 10, 2023

o0HalfLife0o commented Mar 10, 2023

moranno commented Mar 10, 2023 • edited Loading

RPRX commented Mar 10, 2023 • edited Loading

moranno commented Mar 10, 2023 • edited Loading

o0HalfLife0o commented Mar 10, 2023 • edited Loading

moranno commented Mar 10, 2023 • edited Loading

o0HalfLife0o commented Mar 10, 2023

Nyar233 commented Mar 10, 2023 • edited Loading

RPRX commented Mar 10, 2023

RPRX commented Mar 10, 2023

RPRX commented Mar 10, 2023

moranno commented Mar 10, 2023 • edited Loading

RPRX commented Mar 10, 2023

Extreme-Icer commented Mar 10, 2023

RPRX commented Mar 10, 2023

Wyatt323 commented Mar 10, 2023 • edited Loading

moranno commented Mar 10, 2023 • edited Loading

moranno commented Mar 10, 2023 • edited Loading

cross-hello commented Mar 10, 2023

cross-hello commented Mar 10, 2023

RPRX commented Mar 10, 2023

szouc commented Mar 10, 2023

moranno commented Mar 10, 2023

RPRX commented Mar 10, 2023

moranno commented Mar 10, 2023

chika0801 commented Mar 10, 2023

RPRX commented Mar 11, 2023

chika0801 commented Mar 11, 2023 • edited Loading

RPRX commented Mar 12, 2023

zcluo commented Mar 12, 2023

moranno commented Mar 10, 2023 •

edited

Loading

moranno commented Mar 10, 2023 •

edited

Loading

RPRX commented Mar 10, 2023 •

edited

Loading

moranno commented Mar 10, 2023 •

edited

Loading

o0HalfLife0o commented Mar 10, 2023 •

edited

Loading

moranno commented Mar 10, 2023 •

edited

Loading

Nyar233 commented Mar 10, 2023 •

edited

Loading

moranno commented Mar 10, 2023 •

edited

Loading

Wyatt323 commented Mar 10, 2023 •

edited

Loading

moranno commented Mar 10, 2023 •

edited

Loading

moranno commented Mar 10, 2023 •

edited

Loading

chika0801 commented Mar 11, 2023 •

edited

Loading