2021年11月份开始V2Ray很难成功访问成功

[hponiang]

偶尔能打开一个页面，很慢很慢，大家怎么解决的

[xiaokangwang]

可以提供一下配置文件（删除敏感信息），以及具体的服务器的位置么？

[zehuichen123]

@xiaokangwang 这是我的一些信息供参考 如果有问题还请指出
vps是vultr上的 试了新加坡和日本的节点 但是给我的感觉是 服务器端这边有点问题 系统使用的ubuntu 18/20都试过
服务器端配置文件为

{
  "inbounds": [
    {
      "port": xxxx, // 服务器监听端口
      "protocol": "vmess",    // 主传入协议
      "settings": {
        "clients": [
          {
            "id": "xxxx",  // 用户 ID，客户端与服务器必须相同
            "alterId": 233            //这里我64，128都尝试了...
          }
        ]
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",  // 主传出协议
      "settings": {}
    }
  ]
}

理论上应该这样服务端就ok了？
客户端这边我是直接用的shadowrocket，类似这样

这个时候我去点连通性测试都是正常的 大概100～1000ms不等的延迟，但是不会存在超时的情况（update一下 发现有时候也会超时，但是下一次一般能连上），如果此时我在手机上访问google，会直接失败（无法访问此网站），然后此时再点连通性测试一直都是超时，大概等5min左右又能够重新恢复正常连通性测试，但是依然无法登陆google。我更换了几台vps都是一样的结果。
如果是在电脑上用v2rayX的话 我能够在一瞬间打开google，但是是一次性的，之后就访问不到了，这个时候用手机的连通性测试也会超时，然后过5分钟 再用就又可以连一次google，然后挂掉...
所以我感觉是v2ray服务端这边哪里卡住或者出错了？还是我配置有啥问题吗？orz

[xiaokangwang]

现在还有这个问题么？

[xiaokangwang]

我昨天去尝试重现的时候并没能观测到这个行为。

[wangchengao]

我也碰到了，改了传输协议未kcp就莫名好了。inbound 下面加
"streamSettings": {
"network": "kcp"
}

怀疑是GFW能检测到 tcp的vmess协议，直接把包给drop了。

[xiaoma13]

请问你用的哪个节点 换kcp

[wangchengao]

请问你用的哪个节点 换kcp

我在vultra自己搭建的vps。

[zds2]

我也碰到了，改了传输协议未kcp就莫名好了。inbound 下面加 "streamSettings": { "network": "kcp" }

怀疑是GFW能检测到 tcp的vmess协议，直接把包给drop了。

我换了kcp之后，就用了1分钟，然后又不行了，感觉问题大了

[zhaozhiming]

改成kcp后就可以了，困扰了我几天了，谢谢

[omxlyi]

我也碰到了，改了传输协议未kcp就莫名好了。inbound 下面加 "streamSettings": { "network": "kcp" }

怀疑是GFW能检测到 tcp的vmess协议，直接把包给drop了。

能说的更详细一点吗？为什么传输层协议改成kcp居然没事，还有这是客户端还是服务器端的配置文件。你说的方法我还没有尝试，但看起来并不是很靠谱

[wangchengao]

我也碰到了，改了传输协议未kcp就莫名好了。inbound 下面加 "streamSettings": { "network": "kcp" }
怀疑是GFW能检测到 tcp的vmess协议，直接把包给drop了。

能说的更详细一点吗？为什么传输层协议改成kcp居然没事，还有这是客户端还是服务器端的配置文件。你说的方法我还没有尝试，但看起来并不是很靠谱

都要改，可以看这里。https://www.v2fly.org/config/transport/mkcp.html#kcpobject

[Etern213]

可以提供一下配置文件（删除敏感信息），以及具体的服务器的位置么？

出问题的貌似都是vultr的服务器，具体表现就是ip正常，端口正常，所有的都正常，但网络不通。测试延迟会显示context deadline exceeded。换端口无用。应该是所有使用v2ray tcp模式的包全被精准识别然后丢掉了。

配置用的是tcp

[kallydev]

可以提供一下配置文件（删除敏感信息），以及具体的服务器的位置么？

出问题的貌似都是vultr的服务器，具体表现就是ip正常，端口正常，所有的都正常，但网络不通。测试延迟会显示context deadline exceeded。换端口无用。应该是所有使用v2ray tcp模式的包全被精准识别然后丢掉了。

配置用的是tcp

这很难下定论，首先 Vultr 的服务器与大陆之间的路由本身并不友好，以及 Vultr 因为购买门槛低等原因导致其 IP 段很可能被 GFW 重点关注。如果 GFW 检测到无法识别的协议从大陆发送到 Vultr 机房，被丢包也并不是不可能。

需要一些试验数据来验证这些猜想是否成立。

[VirgilMing]

怀疑是vultr被盯上了，所有相关软件版本都是最新
三个节点，西雅图和东南亚的几乎瘫痪，澳洲的目前仍可用（宽带：广东电信/广东移动）
若连移动的热点则均正常
早做准备吧，vultr支持国内支付方式，流量太多了

[hponiang]

我是买 的阿里云新加坡的 轻量服务也不行

[hponiang]

可以提供一下配置文件（删除敏感信息），以及具体的服务器的位置么？
配置和 zehuichen123 一样
服务器在新加坡

[Etern213]

可以提供一下配置文件（删除敏感信息），以及具体的服务器的位置么？

出问题的貌似都是vultr的服务器，具体表现就是ip正常，端口正常，所有的都正常，但网络不通。测试延迟会显示context deadline exceeded。换端口无用。应该是所有使用v2ray tcp模式的包全被精准识别然后丢掉了。
配置用的是tcp

这很难下定论，首先 Vultr 的服务器与大陆之间的路由本身并不友好，以及 Vultr 因为购买门槛低等原因导致其 IP 段很可能被 GFW 重点关注。如果 GFW 检测到无法识别的协议从大陆发送到 Vultr 机房，被丢包也并不是不可能。

需要一些试验数据来验证这些猜想是否成立。

确实我一开始也觉得是自己的问题，后来一想不对劲。我的服务器用了1年半了，自从使用v2ray的tcp协议搭配udp2raw后就从来没出过问题，结果最近突然连接很困难。一检查发现不仅ip没被封，连端口都很正常。

然后发现很多人跟我一样的情况，基本就能确定是v2ray的tcp协议被识破了。目前几个issue里面提到的类似问题，有好几个是用的vultr，并且只有tcp协议会出问题，更换为mkcp后就正常了。

[shuaifengm]

我的也是vultr，更换为mkcp后解决了问题。

[QChWnd]

This sounds a lot like deploying a replay attack based on this approach. But anyway, is there now a way to grab the package to confirm that the GFW has been replayed, or is it a direct identification?

[kallydev]

可以提供一下配置文件（删除敏感信息），以及具体的服务器的位置么？

出问题的貌似都是vultr的服务器，具体表现就是ip正常，端口正常，所有的都正常，但网络不通。测试延迟会显示context deadline exceeded。换端口无用。应该是所有使用v2ray tcp模式的包全被精准识别然后丢掉了。

配置用的是tcp

这很难下定论，首先 Vultr 的服务器与大陆之间的路由本身并不友好，以及 Vultr 因为购买门槛低等原因导致其 IP 段很可能被 GFW 重点关注。如果 GFW 检测到无法识别的协议从大陆发送到 Vultr 机房，被丢包也并不是不可能。

需要一些试验数据来验证这些猜想是否成立。

确实我一开始也觉得是自己的问题，后来一想不对劲。我的服务器用了1年半了，自从使用v2ray的tcp协议搭配udp2raw后就从来没出过问题，结果最近突然连接很困难。一检查发现不仅ip没被封，连端口都很正常。

然后发现很多人跟我一样的情况，基本就能确定是v2ray的tcp协议被识破了。目前几个issue里面提到的类似问题，有好几个是用的vultr，并且只有tcp协议会出问题，更换为mkcp后就正常了。

可能导致连接被阻断的因素有很多，目前的信息还不足以证明 Vmess 能被识别。因为 mKCP 基于 UDP 协议，所以 GFW 对 TCP 和 UDP 的处理规则可能有所不同。

如果实在不放心 Vmess 协议的 TCP 传输模式，建议尝试为其启用 AEAD 和 TLS。

[flwzz]

遇到同样的问题，kcp 也没效

[hponiang]

有解决了的兄弟顶一下哈

[zeratulyxl]

一台vultr的vps，前几天发生上面问题，测试vmess+tcp传输几乎秒封端口（nc测试time out），而且只封端口，不封ip，多久解封不清楚，反正再连再秒封。改用vmess+tcp+tls可以正常稳定连接，另外测试对于vless协议不存在这个问题，只用vless+tcp也不会有任何问题，可以正常稳定连接。所以个人认为可以确认vmess明码可以被精确定位打击。

[xiaoqixian]

方便发一下配置文件吗？

[goalusd]

你好能发一下tls怎么配置吗？我自己没有配置成功。也在vmess + mkcp也不行了

[greader3]

同意，我也认为是“vmess明码可以被精确定位打击”。
我的也是vultr的服务器，用的是VMESS+TCP传输，连接端口就被秒封，并且是仅禁止我pc所在的外网ip，我手机跟pc在同一局域网也无法访问这个ip；但手机在4G环境下，可以telnet通这个端口；在站长工具上显示在国内并未被封；在公司电脑上（刚被封的是家里电脑的外网ip）也可以telnet通这个端口。
后改为vmess+mkcp后，通了。

[xiaokangwang]

昨天我尝试重现这个对于VMess和其他随机协议的封锁，但是无法重现这个问题。 我在Vultr日本，Digital Ocean SFO3(旧金山) 搭建了4种服务器： VMess+TCP, Shadowsockets, 随机数据流, HTTP， 并在超过半个小时的时间内访问这些服务器。然而并没有检测到对这些服务的封锁。 在Vultr日本服务器上运行的Shadowsockets和随机数据流受到了重放探测，探测的方式类似于在GFWReport报告中的R1(原样重放)， 以及R2，R3(修改后重放)。估计在GFWReport给出详细报告后可以得到更详细的重现封锁的方法。对于无法重现这个封锁的事情有3种可能的解释：不同的地区，运营商，用户的限制级别不同;不同的时间限制的级别不同（如开会时封锁会更严格）;以及流量的形状，即在测试时产生的测试流量不会触发针对特性套嵌流量的封锁。

Yesterday, I tried to reproduce that random stream look like nothing proxy blocking behaviour, but it was unsuccessful. All 4 types of service: VMess+TCP, Shadowsockets, Random Stream, HTTP setup at Vultr Japan, Digital Ocean SFO3 is accessible after at least half an hour of usage. Active probe([Identical replay=R1], Partical Replay=R2, R3) are observed at Shadowsockets and Random Stream Service. More information about how to reproduce this may become available once the full report from gfw_report is released. There are 3 possible hypotheses for the non-reproducible characteristic: Different regions and network users might have a different attention score(Vary: User-Identity); This blocking policy is only enacted during sensitive periods like the Party's meeting(Vary: Time); The exact type of traffic determines the blocking behaviour, the traffic synthetic traffic during experiment do not trigger the blocking of its wrapping traffic(Vary: Traffic Shape).

[xiaokangwang]

后来在被重点关注的VPS上重现了。

[greader3]

我的也是vultr的服务器，用的是VMESS+TCP传输，连接端口就被秒封，并且是仅禁止我pc所在的外网ip，我手机跟pc在同一局域网也无法访问这个ip；但手机在4G环境下，可以telnet通这个端口；在站长工具上显示在国内并未被封；在公司电脑上（刚被封的是家里电脑的外网ip）也可以telnet通这个端口。
后改为vmess+mkcp后，通了。

[BurningC4]

grpc也不行

[xhqpp]

昨天我尝试重现这个对于VMess和其他随机协议的封锁，但是无法重现这个问题。 我在Vultr日本，Digital Ocean SFO3(旧金山) 搭建了4种服务器： VMess+TCP, Shadowsockets, 随机数据流, HTTP， 并在超过半个小时的时间内访问这些服务器。然而并没有检测到对这些服务的封锁。 在Vultr日本服务器上运行的Shadowsockets和随机数据流受到了重放探测，探测的方式类似于在GFWReport报告中的R1(原样重放)， 以及R2，R3(修改后重放)。估计在GFWReport给出详细报告后可以得到更详细的重现封锁的方法。对于无法重现这个封锁的事情有3种可能的解释：不同的地区，运营商，用户的限制级别不同;不同的时间限制的级别不同（如开会时封锁会更严格）;以及流量的形状，即在测试时产生的测试流量不会触发针对特性套嵌流量的封锁。

Yesterday, I tried to reproduce that random stream look like nothing proxy blocking behaviour, but it was unsuccessful. All 4 types of service: VMess+TCP, Shadowsockets, Random Stream, HTTP setup at Vultr Japan, Digital Ocean SFO3 is accessible after at least half an hour of usage. Active probe([Identical replay=R1], Partical Replay=R2, R3) are observed at Shadowsockets and Random Stream Service. More information about how to reproduce this may become available once the full report from gfw_report is released. There are 3 possible hypotheses for the non-reproducible characteristic: Different regions and network users might have a different attention score(Vary: User-Identity); This blocking policy is only enacted during sensitive periods like the Party's meeting(Vary: Time); The exact type of traffic determines the blocking behaviour, the traffic synthetic traffic during experiment do not trigger the blocking of its wrapping traffic(Vary: Traffic Shape).

这次是11月初对某些VPS提供商的集体端口干扰 应该是不太好复现的

[CrazyBoyFeng]

重点机房被干扰，很多人用不同的连接方式都被观察到了干扰。
还有，这干扰不是全国性的。我得到的情报是：同一个配置，同省的两个不同运营商有、不同省的同一家运营商，表现均不相同。
触发条件应该不仅是特定机房，可能还包括连接时长和/或流量。

[okudayukiko]

V2Ray-noTLS和SS都沒有金鑰交換。
TLS、L2TP-IPsec-PSK等有金鑰交換的協定還能用。
edit /etc/ipsec.conf
conn %default
#Compatible with Android
ike=aes128-aes256-sha1-sha256-modp1024-modp1536-modp2048-modp3072
esp=aes128-aes256-sha1-sha256
edit /etc/ppp/options.xl2tpd
#Compatible with Android
noccp

[sitsh]

对11 月开会后 一直延续到现在。这里一台受到 间歇性 tcp 阻断的是阿里云 HK 轻量 47.xxxxxx段。
使用 vless +Tls ， brook aes 128 ,Shadowsockets-libev 3.3.5 最新版本 【https://gfw.report/blog/ss_tutorial/zh/】部署，
不同城市 不通运营商 阻断程度不相同， 阻断后一半在 5分钟内恢复，

[kulongwangzhi85]

vless+tls+tcp稳定得很，这配置从升级vless到现在，没阻断过。

[KyoMio]

我的vmess+ws+tls在近期突然就访问不通了，一样的现象客户端报错，改了AEAD也没用，但是同一台服务器上的vless+tls+tcp就不受影响。很迷，找不到原因。

[iHuahua]

最近搞了两个轻量应用，第一个安装的时候是4.43似乎还正常，前两天安装版本是4.44的时候，无论如何都打不开了

[lazydao]

稳定用了一年多的配置最近也不行了

IP+端口 telnet都能通，但v2ray客户端访问就是连不上

app/proxyman/outbound: failed to process outbound traffic > proxy/vmess/outbound: failed to find an available destination > common/retry: [dial tcp -.-.-.65:443: i/o timeout dial tcp -.-.-.65:443: operation was canceled] > common/retry: all retry attempts failed

[iHuahua]

降级可以解决，安装的时候指定一下版本

[Cullwen]

我最后发现是233boy大神的脚本不能用了，换了个脚本就可以了

[GentleWine]

Me too

[lzy19950613]

请问换的哪个脚本呀，可以分享下不

[Cullwen]

Jrohy大神的multi-v2ray脚本：source <(curl -sL https://multi.netlify.app/v2ray.sh) --zh

[lzy19950613]

谢谢！---- 回复的原邮件 ***@***.***>发送日期2022年02月14日 20:24 ***@***.***> ***@***.******@***.***>主题Re: [v2fly/v2ray-core] 2021年11月份开始V2Ray很难成功访问成功 (Discussion #1383) Jrohy大神的multi-v2ray脚本：source <(curl -sL https://multi.netlify.app/v2ray.sh) --zh —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: ***@***.***> [ { ***@***.***": "http://schema.org", ***@***.***": "EmailMessage", "potentialAction": { ***@***.***": "ViewAction", "target": "#1383 (reply in thread)", "url": "#1383 (reply in thread)", "name": "View Discussion" }, "description": "View this Discussion on GitHub", "publisher": { ***@***.***": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

[callmehihi]

我的vmss+tcp运行正常。
你们可能需要检查一下客户端配置信息是不是共享出去了，比如开启了云上贵州的iCloud同步，微信发给别人。这种情况我碰到过瞬间死掉的。反正不要在任何国内平台分享你的配置信息，然后再看看结果怎么样吧。

[IITII]

一般新机器刚搭完就挂的，一般是 IP 有问题，看看能不能直接换一个 IP
自建的WSS 稳定了好几年了

[sansangwuzhi]

我也用的是233的脚本，把协议改成kcp就好了

[realJiaoKan]

最新消息...

人在法国,搭建反向代理的时候被反代的在法国(oracle),做反代的在日本(vultr),他们之间打tunnel的时候,怎么试都不成功,上面说的mkcp、别的比如http、ws等等都试过了,不行......

最后换成websocket+tls+web可以了

所以结论就是,**vultr拦截了别的这些协议,就https没办法拦截而已

[xiaokangwang]

可以提供一下复现方法么？要是vultr真的拦截了这些协议可以给公示一下