Vision流控这两天也开始封端口了，流量特征可能已被识别

[zycboss]

梯子目前只使用vision流控，这几天天所使用的端口用1天就会被封，已经连续3天被封了3个了，各位是否也遇到同样情况？

[chika0801]

说下你的vps商家，帖下你vps服务端配置，说下是1个人用，还是和朋友共用？

[cross-hello]

Could you be sure indeed the port is blocked?

You could use several commands to check.  For example, what will be response if execute telnet ip port.

Jan 21, 2023 10:54:23 zycboss @.***>:

梯子目前只使用vision流控，这几天天所使用的端口用1天就会被封，已经连续3天被封了3个了，各位是否也遇到同样情况？

— Reply to this email directly, view it on GitHub[https://github.com/XTLS/Xray-core/issues/1544], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYGLG7I37VTCURBGSSTWTNFV7ANCNFSM6AAAAAAUCEV6YA]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYDAW5ADEOLPUIYQBI3WTNFV7A5CNFSM6AAAAAAUCEV6YCWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHFY7ESY4.gif]

[xianren78]

多少人都在用trojan都没被封，按社区分析tls in tls早就应该被封完了。现在被封基本上都是VPS重点段，或者被邻居牵扯或者自己折腾的。

[zycboss]

说下你的vps商家，帖下你vps服务端配置，说下是1个人用，还是和朋友共用？

服务商DMIT，洛杉矶CN2 GIA线路，服务端vless+tcp+tls+vision流控，自用，没有共享，没有分流，网络是电信和移动宽带，不过客户端是在两地不同的网络上

[heartboiled]

ban report 服务商SAKURA internet 服务端目前为vision,none和之前的(x)tls，早阵子（大概两个月前）443二进宫后转用444，今晨发现被封 有分流+正常的公共服务，理论上端口上很多正常流量 代理一定程度上有共享（熟人共享）

可能我的稍微有那么一点明显吧

[lns103]

说下你的vps商家，帖下你vps服务端配置，说下是1个人用，还是和朋友共用？

服务商DMIT，洛杉矶CN2 GIA线路，服务端vless+tcp+tls+vision流控，自用，没有共享，网络是电信和移动宽带

你使用的什么端口？我的搬瓦工洛杉矶cn2 GIA之前使用vless+TLS被封了443，现在开了一个新端口用vision，设置了utls，分流cn流量到warp，多人使用，坚持了一个多月，现在还健在

[zycboss]

说下你的vps商家，帖下你vps服务端配置，说下是1个人用，还是和朋友共用？

服务商DMIT，洛杉矶CN2 GIA线路，服务端vless+tcp+tls+vision流控，自用，没有共享，网络是电信和移动宽带

你使用的什么端口？我的搬瓦工洛杉矶cn2 GIA之前使用vless+TLS被封了443，现在开了一个新端口用vision，设置了utls，分流cn流量到warp，多人使用，坚持了一个多月，现在还健在

443最先被封，后来我又开了几个5位数的端口，44443,14443，也接连被封，每天一早起来就没了

[zycboss]

Could you be sure indeed the port is blocked? You could use several commands to check.  For example, what will be response if execute telnet ip port. Jan 21, 2023 10:54:23 zycboss @.***>: … 梯子目前只使用vision流控，这几天天所使用的端口用1天就会被封，已经连续3天被封了3个了，各位是否也遇到同样情况？ — Reply to this email directly, view it on GitHub[#1544], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYGLG7I37VTCURBGSSTWTNFV7ANCNFSM6AAAAAAUCEV6YA]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYDAW5ADEOLPUIYQBI3WTNFV7A5CNFSM6AAAAAAUCEV6YCWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHFY7ESY4.gif]

I am sure the ports were baned, I used https://tcp.ping.pe/ to check ports avialibility, they are unable to reach from China network, other reagions are fine.

[chika0801]

说下你的vps商家，帖下你vps服务端配置，说下是1个人用，还是和朋友共用？

服务商DMIT，洛杉矶CN2 GIA线路，服务端vless+tcp+tls+vision流控，自用，没有共享，网络是电信和移动宽带

你使用的什么端口？我的搬瓦工洛杉矶cn2 GIA之前使用vless+TLS被封了443，现在开了一个新端口用vision，设置了utls，分流cn流量到warp，多人使用，坚持了一个多月，现在还健在

443最先被封，后来我又开了几个5位数的端口，44443,14443，也接连被封，每天一早起来就没了

今天被封的端口是？这端口用vision时间几天？这端口被封前用的端口开的是什么协议组合？

帖下你vps端配置。

[zycboss]

说下你的vps商家，帖下你vps服务端配置，说下是1个人用，还是和朋友共用？

服务商DMIT，洛杉矶CN2 GIA线路，服务端vless+tcp+tls+vision流控，自用，没有共享，网络是电信和移动宽带

你使用的什么端口？我的搬瓦工洛杉矶cn2 GIA之前使用vless+TLS被封了443，现在开了一个新端口用vision，设置了utls，分流cn流量到warp，多人使用，坚持了一个多月，现在还健在

443最先被封，后来我又开了几个5位数的端口，44443,14443，也接连被封，每天一早起来就没了

今天被封的端口是？这端口用vision时间几天？这端口被封前用的端口开的是什么协议组合？

帖下你vps端配置。

今天被封的是44443，之前这端口没开过，我是昨天才开的，今天就被封了，整个VPS从11月开始我就只用vision流控，一直是只开443端口用的，但是443是前几天被封，我才开始换其他端口 服务端置是vless+tcp+tls+vision，没开其他的协议

[FranzKafkaYu]

其实应该提一下客户端信息，包括平台与配置信息

[RPRX]

说起 DMIT，现在的人，总是喜欢事情还没搞清楚，就先起个大新闻的标题，内涵一下 https://github.com/XTLS/Xray-core/issues/1503

相对于 XTLS Vision 的使用基数，目前几乎没有收到 配置正确 的 Vision 被封端口的报告，配置正确 指的是：

1. 服务端使用合理的端口，禁回国流量
2. 只配置 XTLS Vision，不兼容普通 TLS 代理
3. 回落到网页，不回落/分流到其它代理协议
4. 客户端启用 uTLS（fingerprint）

ban report 服务商SAKURA internet 服务端目前为vision,none和之前的(x)tls，早阵子（大概两个月前）443二进宫后转用444，今晨发现被封 有分流+正常的公共服务，理论上端口上很多正常流量 代理一定程度上有共享（熟人共享）

可能我的稍微有那么一点明显吧

@heartboiled Vision 默认不兼容普通 TLS 代理是有原因的，因为兼容的话，Vision 的努力就白费了，要做好随时被封的心理准备。 就在昨天，我刚好看到了一个特别搞笑的事情：

我把xtls rprx vision分享给朋友 然后他问我iOS端怎么办 我只好又分享了一份vless tls tcp版本的 然后隔天给我封了端口号 一问 他妈的直接给电脑上的V2rayN用 然后V2rayN的版本和xray core一年多没更新了 真是无语 老版本V2rayN连utls的选项都没有 有什么方法能自动拒绝低版本xray core以及不带指纹伪装的低版本客户端连接 这群傻逼非常不自觉 三令五申不准开全局模式用 算是记住了 然后又不更新客户端 我以后就分享xtls rprx vision版本 iOS小火箭用不了拉倒 连不上别问我怎么回事 自己升级客户端版本去

所以说，开 Vision 却兼容旧代理协议分享给别人用，你根本想不到别人会怎么霍霍，这是你无法控制的。 如果你只分享了 Vision，那本质上就已经筛选掉了没指纹选项的旧客户端，这也是 Vision 相对于众多旧代理协议的优势之一。

说回这个 issue，@zycboss 我认为你端口被封的原因并不是“流量特征可能已被识别”，我们可以先假设这一命题成立，那么一定会有大规模的端口被封报告，而这是没有发生的，故，命题不成立。再说，你指望 GFW 相关单位/企业春节不回家加班搞研发应用也不太现实。你端口被封应该是触发了 GFW 的旧规则，有可能是使用姿势不正确导致的，也有可能是 IP 段重点或不干净导致的。

寻找原因、寻求帮助，是完全可以的。但还是那句话，事情还没搞清楚之前，不要总想着弄个大新闻。

[cross-hello]

China cooperation overwork in Spring Festival

[heartboiled]

@heartboiled Vision 默认不兼容普通 TLS 代理是有原因的，因为兼容的话，Vision 的努力就白费了，要做好随时被封的心理准备。

今天晚上又解封了，感觉是抽检啊

[fuokgfw]

我的还建在，很大可能是使用了全局模式才会被封

[simpleandstupid]

vision端口（高位）没了，过CDN的ws/grpc还活着。客户端都是core1.7.2

[heartboiled]

vision端口（高位）没了

为什么要用高位？简直会动的肉靶子

[simpleandstupid]

vision端口（高位）没了

为什么要用高位？简直会动的肉靶子

历史因素，这个我就不赞同了。 高位端口已经稳定一年多了（在vision出来前同端口是direct）

[RPRX]

vision端口（高位）没了

为什么要用高位？简直会动的肉靶子

历史因素，这个我就不赞同了。 高位端口已经稳定一年多了（在vision出来前同端口是direct）

根据已知的信息，对 TLS 的封端口是基于事后流量分析，有一天或更长时间的延迟。所以有没有一种可能，就是因为同端口以前经常跑 direct，才会导致迟到的封端口？没有控制变量，参考价值大打折扣。

[RPRX]

由于（至少目前）无 XTLS Vision 的大规模被封报告，无法推出该 issue 标题的后半段，且 @zycboss 无回复，我将关闭该 issue。 有一些事情我需要在这里说明，以供后人参考。

首先，如果你特别不想被封，请先选择一个干净的 IP，并按照我说的 配置正确 去搭建、使用 XTLS Vision。

但是，即使你这样做了，也无法保证 100% 不被封。自去年底始，很多人的未知流量秒封 IP，TLS in TLS 流量隔天封端口。XTLS Vision 不是未知流量，且完整处理了 TLS in TLS 特征，目前看来效果显著。但这并不意味着，用 XTLS Vision 可以 100% 不被封，认识到这一点是非常、非常重要的，不要自己偶然被封就大惊小怪。

因为除了协议本身，还有很多角度能封你。以 IP 为例，你无法保证 IP 真的干净，无法避免被邻居波及，无法避免整个 IP 段被重点拉清单。也有可能某些地区的 GFW 有独特的标准，比如某个 IP 只有寥寥数人访问却能跑那么多流量，封。如果你的 XTLS Vision 被封了，但没有出现去年底 TLS 那样的大规模被封报告，我真心建议你换端口、换 IP、换服务商依次试一遍。

XTLS Vision 完全没有特征吗？也不是，我就可以把它封得很精准。此外，两年前我就想出了很多种角度来不带 collateral damage 地精准封锁 FQ 流量，一个不剩。当时我连文章草稿都写好了，只是没发，还是不给 GFW 提供弹药了，万一他们还没想到。

最后，没看过黑镜第一季第一集的，建议去看一遍。

[RPRX]

看了下群，有人说我也可能是在吹牛，真的是有够搞笑，那我就给你们说一个最低级的、现存的但能修复的吧，也算没提供弹药。 去年底很多人纳闷为什么节点到了 v2rayNG 上就容易被封，到处找原因，什么奇葩理论都出来了。 最简单的，v2rayNG 下面是不是有一个测延迟，是不是喜欢有事没事就点一下？不如看一看一来一回流量长度特征有多刺眼？ 而且它不是 TLS，没握手 padding，连 XTLS Vision 测延迟都非常刺眼。对于针对性封锁，这只是最低级的方法，其它的还不能说。 （可能有人会说随机 padding 可以解决？简单取个平均，用什么 padding 的，底裤都给你扒出来）

[cross-hello]

We always suspect v2rayng is supported via government, otherwise willn't show out many problems(and it is not really open source).

[SakuraSakuraSakuraChan]

@cross-hello Who is "we"?

[cross-hello]

The ones who are saying.

Jan 25, 2023 00:29:51 SakuraSakuraSakuraChan @.***>:

@cross-hello[https://github.com/cross-hello] Who is "we"?

— Reply to this email directly, view it on GitHub[https://github.com/XTLS/Xray-core/issues/1544#issuecomment-1402233202], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYFBMDLONFVGNGSRPS3WT77P3ANCNFSM6AAAAAAUCEV6YA]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYCYVMWMGQDMZCZQ3ULWT77P3A5CNFSM6AAAAAAUCEV6YCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSTSRQXE.gif]

[RPRX]

We always suspect v2rayng is supported via government

Wrong.

@cross-hello Who is "we"?

Himself @cross-hello

[SakuraSakuraSakuraChan]

@cross-hello Who is saying? Source request

[Fangliding]

@cross-hello 有没有可能NG的一位开发者同时也是Xray的

[cross-hello]

Sorry, may be wrong.

But there are some secure options v2rayng don't intend to provide(like MUX) or others.

We dont understand the cause.

[RPRX]

@cross-hello Who is saying? Source request

他的英语语法不太标准，他说的 We 都需要替换成 I，我已经看习惯了，不必深究。。。

[heartboiled]

他的英语语法不太标准，他说的 We 都需要替换成 I，我已经看习惯了，不必深究。。。

也许是分离性身份识别障碍患者 some link

[RPRX]

@heartboiled 没有必要这样说别人吧

[StarPriest]

说下你的vps商家，帖下你vps服务端配置，说下是1个人用，还是和朋友共用？

服务商DMIT，洛杉矶CN2 GIA线路，服务端vless+tcp+tls+vision流控，自用，没有共享，网络是电信和移动宽带

你使用的什么端口？我的搬瓦工洛杉矶cn2 GIA之前使用vless+TLS被封了443，现在开了一个新端口用vision，设置了utls，分流cn流量到warp，多人使用，坚持了一个多月，现在还健在

相同机房，相同遭遇，相同操作，相同结果。 原443换8443，某天夜里无聊，换roueros系统，之后常规telnet vps 443，居然解封了。遂换回linux， xray-core 前置 443走起。

[chenhans233]

我在美国multacom机房用vless+tcp+xtls，控流direct上443被封口，后来换vision用8443到现在没有封口，但是阻断特别严重，没用一会就断几分钟才好然后又是循环。

[3xpert]

为什么节点到了 v2rayNG 上就容易被封

所以，大佬有什么android客户端推荐吗？用过AnXray SageNet现在都停更了。现在一直用v2rayNG，我有一节点很奇怪，在openwrt上的透明代理跑得很正常，但在android手机上只能偶尔测速有反应，大多数时间都是io:read/write on closed pipe，这个现象是在开始用vision流控后开始的（但切换到direct流控后依旧是io:read/write on closed pipe，所以我想跟流控无关），但其它的节点却能正常跑起。这些节点的服务器和客户端配置完全一样。也怀疑移动和家宽（都是电信的）的墙是不是有不同的规则，换过IP，但结果也一样。试了一下matsuri，跑了一很短时间，也不通了。

[chika0801]

没有了。大佬意思是平时没事别手痒点测速。

[zycboss]

由于（至少目前）无 XTLS Vision 的大规模被封报告，无法推出该 issue 标题的后半段，且 @zycboss 无回复，我将关闭该 issue。 有一些事情我需要在这里说明，以供后人参考。

首先，如果你特别不想被封，请先选择一个干净的 IP，并按照我说的 配置正确 去搭建、使用 XTLS Vision。

但是，即使你这样做了，也无法保证 100% 不被封。自去年底始，很多人的未知流量秒封 IP，TLS in TLS 流量隔天封端口。XTLS Vision 不是未知流量，且完整处理了 TLS in TLS 特征，目前看来效果显著。但这并不意味着，用 XTLS Vision 可以 100% 不被封，认识到这一点是非常、非常重要的，不要自己偶然被封就大惊小怪。

因为除了协议本身，还有很多角度能封你。以 IP 为例，你无法保证 IP 真的干净，无法避免被邻居波及，无法避免整个 IP 段被重点拉清单。也有可能某些地区的 GFW 有独特的标准，比如某个 IP 只有寥寥数人访问连却能跑那么多流量，封。如果你的 XTLS Vision 被封了，但没有出现去年底 TLS 那样的大规模被封报告，我真心建议你换端口、换 IP、换服务商依次试一遍。

XTLS Vision 完全没有特征吗？也不是，我就可以把它封得很精准。此外，两年前我就想出了很多种角度来不带 collateral damage 地精准封锁 FQ 流量，一个不剩。~当时我连文章草稿都写好了，只是没发，还是不给 GFW 提供弹药了，万一他们还没想到~。

最后，没看过黑镜第一季第一集的，建议去看一遍。

这两天我在控制变量做测试，目前我将流控从常规的xtls-rprx-vision改成xtls-rprx-vision-udp443走udp，就没有再继续被封端口了，你说的机房/线路/邻居被重点照顾盯上的情况的确可能性比较大，我会再继续测试一段时间看看

[chika0801]

xtls-rprx-vision-udp443，这流控不是走udp的意思，你去看下文档。你要测试走udp的协议用hysteria。

[zycboss]

昨天把客户端流控改回xtls-rprx-vision，今早端口被封，从改设置到被封时间不到24小时 本次献祭端口号: 1443 之前此端口在xtls-rprx-vision-udp443流控下正常使用超过72小时，其他之前被封的端口也是在xtls-rprx-vision流控下被封，我可以继续测试xtls-rprx-vision-udp443

在楼上 @chika0801 提醒后我查阅文档，xtls-rprx-vision-udp443和xtls-rprx-vision的区别只是放行了443端口的UDP流量，那么我有一些疑问: 我的443端口是最早被墙的，为何现在还可以走UDP流量？ 代理的UDP流量是否有也是墙识别的一个特征？为何只是放行了UDP流量就不封了？ 443端口的UDP流量从何而来？是某些游戏客户端(如steam)会用到吗？

[H1JK]

@zycboss Normal flows reject all UDP packets that have been sent to 443 port on any destinations because more and more modern websites start supporting QUIC, and XTLS only works on TLS so it would be better to prevent browsers from using QUIC to enable XTLS feature.

For that, it has the same effect to add this to rule:

{
  "type": "field",
  "port": "443",
  "network": "udp",
  "inboundTag": ["YOUR_INBOUND_TAG"],
  "outboundTag": "block" // a blackhole outbound
}

VLESS/VMess/Trojan NEVER use UDP (except mKCP and QUIC) for transport. All UDP packets are tranfered through XUDP tunnel, a UDP over TCP multiplexing keep-alive connection.

443端口的UDP流量从何而来？

It's the standard port of QUIC, mostly from your browser.

[Kissycat]

为什么节点到了 v2rayNG 上就容易被封

在openwrt上的透明代理跑得很正常

你自己不就给出答案了，root跑透明代理嘛，客户端配置自己写，透明代理的方案可以参考这个

[chika0801]

我的443端口是最早被墙的，为何现在还可以走UDP流量？ 443的TCP被封，不代表443的UDP被封。TCP和UDP是分开的。

代理的UDP流量是否有也是墙识别的一个特征？为何只是放行了UDP流量就不封了？ 你不说你的使用环境，比如PC上用v2rayN，没开TUN全局代理，手机上用v2rayNG分应用代理，还是路由器刷openwrt安插件代理。环境不知道，猜不出来。只有透明代理时，你正确设置了，UDP流量会被代理，如果是vless协议，UDP over TCP传输。基本的网络知识建议多搜索自学下，几句话打字也讲不清楚。

443端口的UDP流量从何而来？是某些游戏客户端(如steam)会用到吗？ 如果你是透明代理环境，你的浏览器特意设置过了，可能访问如ytb会请求udp 443。你不说你的环境，我给你说一般人都走不到udp 443的请求。

另外要别人帮助，前面就叫你细说，帖下VPS配置之类，真的不愿意提供或你没看到我们回的消息的话，真帮不了，猜不出来。建议你直接去看hysteria换协议得了。TCP类的不适合你的VPS商家。

[yuhan6665]

我也占卜一个。。有没有人用的 randomized 指纹？R佬发现了一个漏洞 randomized 会协商出 TLS 1.2。GFW 一看你们这些小可爱。。

下个版本会修复

[RPRX]

我也占卜一个。。有没有人用的 randomized 指纹？R佬发现了一个漏洞 randomized 会协商出 TLS 1.2。GFW 一看你们这些小可爱。。

下个版本会修复

虽然但是，肯定不是这个原因（至于为什么，我会在 Reality 的文章中详细说明，至于什么时候会发，我只能说还没动笔）

这个 issue 表现出来的更像是 IP 有前科，追着端口封。其实一个跑 TLS 的端口被封后，马上开另一个端口跑 TLS 也是一个非常刺眼的特征。只是目前来看，并不是所有地区的 GFW 都会追着封，也并不是所有的 IP 段都有这个待遇。有可能他的 IP 享受了此待遇。

还有可能，是域名有前科、服务端指纹等，但这些问题已经被 Reality 解决了，至于什么时候放代码，取决于你的进度，加油！ 甚至有一种超出你们认知的可能，是人有“前科”，追着他用的 FQ 方式封，这种只能说是太狠了，一点游戏体验都不给。 国内上网都是实名的，想永封在座重度 FQ 的各位，技术上完全可以实现，只是目前没必要这样做，且 F 且珍惜。

@zycboss 确实应当先把配置贴上来，至今大家连你有没有在服务端处理回国流量都不知道，一直在猜谜。

或许我们应该搞些 issue 模板 @yuhan6665

[chika0801]

这iss的积极作用是让r主席透露了更多Reality的信息

[zycboss]

我的443端口是最早被墙的，为何现在还可以走UDP流量？ 443的TCP被封，不代表443的UDP被封。TCP和UDP是分开的。

代理的UDP流量是否有也是墙识别的一个特征？为何只是放行了UDP流量就不封了？ 你不说你的使用环境，比如PC上用v2rayN，没开TUN全局代理，手机上用v2rayNG分应用代理，还是路由器刷openwrt安插件代理。环境不知道，猜不出来。只有透明代理时，你正确设置了，UDP流量会被代理，如果是vless协议，UDP over TCP传输。基本的网络知识建议多搜索自学下，几句话打字也讲不清楚。

443端口的UDP流量从何而来？是某些游戏客户端(如steam)会用到吗？ 如果你是透明代理环境，你的浏览器特意设置过了，可能访问如ytb会请求udp 443。你不说你的环境，我给你说一般人都走不到udp 443的请求。

另外要别人帮助，前面就叫你细说，帖下VPS配置之类，真的不愿意提供或你没看到我们回的消息的话，真帮不了，猜不出来。建议你直接去看hysteria换协议得了。TCP类的不适合你的VPS商家。

很抱歉过年事情比较多，没有办法专心花很多时间排障 现在把服务断的inbounds配置贴出来请帮忙看一下，域名相关的地方我划掉(&&)了，希望没有影响

服务端配置

``` { "inbounds": [ { "port": 443, "protocol": "vless", "tag": "VLESSTCP", "settings": { "clients": [ { "id": "bbf079fb-b011-46e2-91d4-6596c6473901", "add": "", "flow": "xtls-rprx-vision", "email": "www.&&&&&&_bbf079fb-b011-46e2-91d4-6596c6473901" } ], "decryption": "none", "fallbacks": [ { "dest": 31300, "xver": 0 }, { "alpn": "h2", "dest": 31302, "xver": 0 } ] }, "streamSettings": { "network": "tcp", "security": "tls", "tlsSettings": { "minVersion": "1.2", "alpn": [ "http/1.1", "h2" ], "certificates": [ { "certificateFile": "/etc/v2ray-agent/tls/www.&&&&&&.crt", "keyFile": "/etc/v2ray-agent/tls/www.&&&&&&.key", "ocspStapling": 3600, "usage": "encipherment" } ] } } } ] } ```

客户端目前我用了openwrt端的bypass，还有一个梅林的koolshare科学上网插件，都是路由器上的 没有用PC端的v2rayN和手机端的v2rayNG

需要的话我可以把客户端的配置文件也想办法导出来看一下

[cross-hello]

Read your past comment for vision on router support, we had guessed you using OpenWrt. 🤭

Though may know nothing else 🙃

Jan 26, 2023 22:06:41 zycboss @.***>:

我的443端口是最早被墙的，为何现在还可以走UDP流量？ 443的TCP被封，不代表443的UDP被封。TCP和UDP是分开的。

代理的UDP流量是否有也是墙识别的一个特征？为何只是放行了UDP流量就不封了？ 你不说你的使用环境，比如PC上用v2rayN，没开TUN全局代理，手机上用v2rayNG分应用代理，还是路由器刷openwrt安插件代理。环境不知道，猜不出来。只有透明代理时，你正确设置了，UDP流量会被代理，如果是vless协议，UDP over TCP传输。基本的网络知识建议多搜索自学下，几句话打字也讲不清楚。

443端口的UDP流量从何而来？是某些游戏客户端(如steam)会用到吗？ 如果你是透明代理环境，你的浏览器特意设置过了，可能访问如ytb会请求udp 443。你不说你的环境，我给你说一般人都走不到udp 443的请求。

另外要别人帮助，前面就叫你细说，帖下VPS配置之类，真的不愿意提供或你没看到我们回的消息的话，真帮不了，猜不出来。建议你直接去看hysteria换协议得了。TCP类的不适合你的VPS商家。

很抱歉过年事情比较多，没有办法专心花很多时间排障 现在把服务断的inbounds配置贴出来请帮忙看一下，域名相关的地方我划掉(&&)了，希望没有影响

服务端配置 { "inbounds": [ { "port": 443, "protocol": "vless", "tag": "VLESSTCP", "settings": { "clients": [ { "id": "bbf079fb-b011-46e2-91d4-6596c6473901", "add": "", "flow": "xtls-rprx-vision", "email": "www.&&&&&&_bbf079fb-b011-46e2-91d4-6596c6473901" } ], "decryption": "none", "fallbacks": [ { "dest": 31300, "xver": 0 }, { "alpn": "h2", "dest": 31302, "xver": 0 } ] }, "streamSettings": { "network": "tcp", "security": "tls", "tlsSettings": { "minVersion": "1.2", "alpn": [ "http/1.1", "h2" ], "certificates": [ { "certificateFile": "/etc/v2ray-agent/tls/www.&&&&&&.crt", "keyFile": "/etc/v2ray-agent/tls/www.&&&&&&.key", "ocspStapling": 3600, "usage": "encipherment" } ] } } } ] } 客户端目前我用了openwrt端的bypass，还有一个梅林的koolshare科学上网插件，都是路由器上的 没有用PC端的v2rayN和手机端的v2rayNG

需要的话我可以把客户端的配置文件也想办法导出来看一下

— Reply to this email directly, view it on GitHub[https://github.com/XTLS/Xray-core/issues/1544#issuecomment-1405054251], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYDEEILR7CAPCM6BSDTWUKAHBANCNFSM6AAAAAAUCEV6YA]. You are receiving this because you were mentioned.[Tracking image][https://github.com/notifications/beacon/AKGBAYGAKNGNVJLHDLLDD5DWUKAHBA5CNFSM6AAAAAAUCEV6YCWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSTX5WSW.gif]

[RPRX]

@zycboss 大哥，我现在最关心的是，服务端有没有处理回国流量？我的建议是全禁掉，当然走 Warp 也行，只是 XTLS 会被记录 早在两年前我就说过，服务端必须禁掉回国流量，现在已经是基本操作了，去年底也有实验表明回国流量确实会导致 SS IP 被封 但是根据你问出的问题，我合理怀疑你并没有（可能是不会）这样配置，如果真的没有，血压很难下来

给大家带来一个 Reality 的好消息，为什么没有年前放出，因为很显然过年大家心思都不在这上面，年前放出太冷清 所以我选择过年玩几天，等 Xray-core 代码更完善了再集成 Reality，显然 @yuhan6665 也选择了过年玩几天 现在开始，我也会推进 Xray-core 这边的进度，如果顺利，月底 Reality 就能和大家见面了，否则会推到 Go 1.20

还有，群里别担心什么 SNI 白名单了，我早就说了 VLESS + XTLS Vision + REALITY 可解，秒天秒地秒空气的那种，只是鸽了两年

[Fangliding]

@RPRX Sodayo

[chika0801]

主席的隔空喊话机器人都送到了233

[zycboss]

@zycboss 大哥，我现在最关心的是，服务端有没有处理回国流量？我的建议是全禁掉，当然走 Warp 也行，~只是 XTLS 会被记录~ 早在两年前我就说过，服务端必须禁掉回国流量，现在已经是基本操作了，去年底也有实验表明回国流量确实会导致 SS IP 被封 但是根据你问出的问题，我合理怀疑你并没有（可能是不会）这样配置，~如果真的没有，血压很难下来~

给大家带来一个 Reality 的好消息，~为什么没有年前放出，因为很显然过年大家心思都不在这上面，年前放出太冷清~ 所以我选择过年玩几天，等 Xray-core 代码更完善了再集成 Reality，~显然 @yuhan6665 也选择了过年玩几天~ 现在开始，我也会推进 Xray-core 这边的进度，如果顺利，月底 Reality 就能和大家见面了，~否则会推到 Go 1.20~

~还有，群里别担心什么 SNI 白名单了，我早就说了 VLESS + XTLS Vision + REALITY 可解，秒天秒地秒空气的那种，只是鸽了两年~

感谢提供思路，我之前有了解过屏蔽回国流量的做法，但是我自己的确没有做屏蔽，主要原因如下：

1. 我偶尔会需要用到全局代理的情况，所以直接屏蔽会造成使用上一定的不便；
2. 我认为最近端口被封，回国流量并不是或者至少不是主要原因，我分析如下：
   • 2022年10月份开始大规模封禁的时候，我尝试更换过很多协议和组合，trojan，trojan-go，naive，grpc等，都无一例外很快被封IP；
   • 2022年11月客户端开始支持vision流控，我开始使用vision流控后，一直都没有再被封禁，一直到2023年1月年前的几天；
   • 在此期间我是用的客户端除了版本和配置上的更新，网络环境和系统都没有变过；
   • 在此期间所有更换的IP地址，也都是同一个IP段，所以应该不存在此IP段在年前突然被重点加强照顾的情况；
   • 在使用vision流控的之前和之后也都没有屏蔽过回国流量。

不过现在问题根源不好确定，还是只能控制变量+排除法，无非就是再献祭一个端口而已 所以我已按照你提供的方案，在outbounds里屏蔽geoip:cn回国流量，同时更新了服务端的geosite.dat与geoip.dat

我已将客户端的流控从xtls-rprx-vision-udp443换回xtls-rprx-vision 我明天会再来更新报告端口是否仍然被封禁

outbounds配置

``` { "outbounds":[ { "protocol":"freedom", "settings":{ "domainStrategy":"UseIPv4" }, "tag":"IPv4-out" }, { "protocol":"freedom", "settings":{ "domainStrategy":"UseIPv6" }, "tag":"IPv6-out" }, { "protocol": "blackhole", "settings": { "response": { "type": "http" } }, "tag": "blocked" } ] }, "routing": { "domainStrategy": "IPOnDemand", "rules": [ { "domain": [ "geosite:cn" ], "outboundTag": "blocked", "type": "field" }, { "ip": [ "geoip:cn" ], "outboundTag": "blocked", "type": "field" } ] }