Vision流控这两天也开始封端口了，流量特征可能已被识别 #1544
Comments
|
说下你的vps商家，帖下你vps服务端配置，说下是1个人用，还是和朋友共用？ |
|
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]
|
|
多少人都在用trojan都没被封，按社区分析tls in tls早就应该被封完了。现在被封基本上都是VPS重点段，或者被邻居牵扯或者自己折腾的。 |
服务商DMIT，洛杉矶CN2 GIA线路，服务端vless+tcp+tls+vision流控，自用，没有共享，没有分流，网络是电信和移动宽带，不过客户端是在两地不同的网络上 |
|
ban report 可能我的稍微有那么一点明显吧 |
你使用的什么端口？我的搬瓦工洛杉矶cn2 GIA之前使用vless+TLS被封了443，现在开了一个新端口用vision，设置了utls，分流cn流量到warp，多人使用，坚持了一个多月，现在还健在 |
443最先被封，后来我又开了几个5位数的端口，44443,14443，也接连被封，每天一早起来就没了 |
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. |
今天被封的端口是？这端口用vision时间几天？这端口被封前用的端口开的是什么协议组合？ 帖下你vps端配置。 |
今天被封的是44443，之前这端口没开过，我是昨天才开的，今天就被封了，整个VPS从11月开始我就只用vision流控，一直是只开443端口用的，但是443是前几天被封，我才开始换其他端口 |
|
其实应该提一下客户端信息，包括平台与配置信息 |
|
相对于 XTLS Vision 的使用基数，目前几乎没有收到 配置正确 的 Vision 被封端口的报告，配置正确 指的是：
@heartboiled Vision 默认不兼容普通 TLS 代理是有原因的，因为兼容的话，Vision 的努力就白费了，要做好随时被封的心理准备。
所以说，开 Vision 却兼容旧代理协议分享给别人用，你根本想不到别人会怎么霍霍，这是你无法控制的。 说回这个 issue，@zycboss 我认为你端口被封的原因并不是“流量特征可能已被识别”，我们可以先假设这一命题成立，那么一定会有大规模的端口被封报告，而这是没有发生的，故，命题不成立。再说，你指望 GFW 相关单位/企业春节不回家加班搞研发应用也不太现实。你端口被封应该是触发了 GFW 的旧规则，有可能是使用姿势不正确导致的，也有可能是 IP 段重点或不干净导致的。 寻找原因、寻求帮助，是完全可以的。但还是那句话， |
|
今天晚上又解封了，感觉是抽检啊 |
|
我的还建在，很大可能是使用了全局模式才会被封 |
|
vision端口（高位）没了，过CDN的ws/grpc还活着。客户端都是core1.7.2 |
为什么要用高位？简直会动的肉靶子 |
历史因素，这个我就不赞同了。 |
根据已知的信息，对 TLS 的封端口是基于事后流量分析，有一天或更长时间的延迟。所以有没有一种可能，就是因为同端口以前经常跑 direct，才会导致迟到的封端口？没有控制变量，参考价值大打折扣。 |
|
由于（至少目前）无 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 流量，一个不剩。 最后，没看过黑镜第一季第一集的，建议去看一遍。 |
|
看了下群， |
|
We always suspect v2rayng is supported via government, otherwise willn't show out many problems(and it is not really open source).
|
|
@cross-hello Who is "we"? |
|
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[#1544 (comment)], 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]
|
Wrong.
Himself @cross-hello |
|
@cross-hello Who is saying? Source request |
|
@cross-hello 有没有可能NG的一位开发者同时也是Xray的 |
|
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.
|
他的英语语法不太标准，他说的 We 都需要替换成 I，我已经看习惯了，不必深究。。。 |
也许是分离性身份识别障碍患者 some link |
|
@heartboiled |
相同机房，相同遭遇，相同操作，相同结果。 |
|
我在美国multacom机房用vless+tcp+xtls，控流direct上443被封口，后来换vision用8443到现在没有封口，但是阻断特别严重，没用一会就断几分钟才好然后又是循环。 |
所以，大佬有什么android客户端推荐吗？用过AnXray SageNet现在都停更了。现在一直用v2rayNG，我有一节点很奇怪，在openwrt上的透明代理跑得很正常，但在android手机上只能偶尔测速有反应，大多数时间都是io:read/write on closed pipe，这个现象是在开始用vision流控后开始的（但切换到direct流控后依旧是io:read/write on closed pipe，所以我想跟流控无关），但其它的节点却能正常跑起。这些节点的服务器和客户端配置完全一样。也怀疑移动和家宽（都是电信的）的墙是不是有不同的规则，换过IP，但结果也一样。试了一下matsuri，跑了一很短时间，也不通了。 |
|
没有了。大佬意思是平时没事别手痒点测速。 |
这两天我在控制变量做测试，目前我将流控从常规的xtls-rprx-vision改成xtls-rprx-vision-udp443走udp，就没有再继续被封端口了，你说的机房/线路/邻居被重点照顾盯上的情况的确可能性比较大，我会再继续测试一段时间看看 |
|
xtls-rprx-vision-udp443，这流控不是走udp的意思，你去看下文档。你要测试走udp的协议用hysteria。 |
|
昨天把客户端流控改回xtls-rprx-vision，今早端口被封，从改设置到被封时间不到24小时 在楼上 @chika0801 提醒后我查阅文档，xtls-rprx-vision-udp443和xtls-rprx-vision的区别只是放行了443端口的UDP流量，那么我有一些疑问: |
|
@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.
It's the standard port of QUIC, mostly from your browser. |
你自己不就给出答案了，root跑透明代理嘛，客户端配置自己写，透明代理的方案可以参考这个 |
|
我的443端口是最早被墙的，为何现在还可以走UDP流量？ 代理的UDP流量是否有也是墙识别的一个特征？为何只是放行了UDP流量就不封了？ 443端口的UDP流量从何而来？是某些游戏客户端(如steam)会用到吗？ 另外要别人帮助，前面就叫你细说，帖下VPS配置之类，真的不愿意提供或你没看到我们回的消息的话，真帮不了，猜不出来。建议你直接去看hysteria换协议得了。TCP类的不适合你的VPS商家。 |
|
我也占卜一个。。有没有人用的 randomized 指纹？R佬发现了一个漏洞 randomized 会协商出 TLS 1.2。GFW 一看你们这些小可爱。。 下个版本会修复 |
虽然但是，肯定不是这个原因（至于为什么，我会在 Reality 的文章中详细说明，至于什么时候会发， 这个 issue 表现出来的更像是 IP 有前科，追着端口封。其实一个跑 TLS 的端口被封后，马上开另一个端口跑 TLS 也是一个非常刺眼的特征。只是目前来看，并不是所有地区的 GFW 都会追着封，也并不是所有的 IP 段都有这个待遇。 还有可能，是域名有前科、服务端指纹等，但这些问题已经被 Reality 解决了，至于什么时候放代码， @zycboss 确实应当先把配置贴上来，至今大家连你有没有在服务端处理回国流量都不知道， 或许我们应该搞些 issue 模板 @yuhan6665 |
|
这iss的积极作用是让r主席透露了更多Reality的信息 |
很抱歉过年事情比较多，没有办法专心花很多时间排障 服务端配置客户端目前我用了openwrt端的bypass，还有一个梅林的koolshare科学上网插件，都是路由器上的 需要的话我可以把客户端的配置文件也想办法导出来看一下 |
|
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[#1544 (comment)], 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]
|
|
@zycboss 大哥，我现在最关心的是，服务端有没有处理回国流量？我的建议是全禁掉，当然走 Warp 也行， 给大家带来一个 Reality 的好消息，
|
|
@RPRX Sodayo |
|
主席的隔空喊话机器人都送到了233 |
感谢提供思路，我之前有了解过屏蔽回国流量的做法，但是我自己的确没有做屏蔽，主要原因如下：
不过现在问题根源不好确定，还是只能控制变量+排除法，无非就是再献祭一个端口而已 我已将客户端的流控从xtls-rprx-vision-udp443换回xtls-rprx-vision outbounds配置 |
如果全局模式需要用到，建议尝试将geosite/ip:CN路由到wireguard出口，并配置一个corn任务每日定期更新geosite/geoip，保持这两个文件最新，尽量减少漏网之鱼。我之前一直block geosite：CN，现在放wg出口，同一个ip使用已经超过三年 端口也没封过，还看流媒体，流量也不小，也可能是幸存者偏差 |
|
@zycboss 建议你不要在vps端配置使用geosite cn，因为你客户端是路由器透明代理，用了这个，会遇到一些google网址（比如翻译）在vps端被阻止的莫名问题。 比如示例里，只用了geoip cn 阻止 https://github.com/XTLS/Xray-examples/blob/995be44bfcbfe5f270e8572dd6ce874a17fa44a8/VLESS-TCP-XTLS-Vision/config_server.json#L11 参见geo加强版的说明 |
目前只是临时测试，如果有长期使用需要我会再进行配置上的优化 奇怪的是，vision流控下被封的都是端口，这次IP一直没被封，之前10月大规模封禁的时候基本上先封一个端口，第二次就是直接封IP了 |
梯子目前只使用vision流控，这几天天所使用的端口用1天就会被封，已经连续3天被封了3个了，各位是否也遇到同样情况？
The text was updated successfully, but these errors were encountered: