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

[wangchengao]

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

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

[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后就正常了。

[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明码可以被精确定位打击。