Closed hponiang closed 2 years ago
可以提供一下配置文件(删除敏感信息),以及具体的服务器的位置么?
@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
我也碰到了,改了传输协议未kcp就莫名好了。inbound 下面加 "streamSettings": { "network": "kcp" }
怀疑是GFW能检测到 tcp的vmess协议,直接把包给drop了。
我也碰到了,改了传输协议未kcp就莫名好了。inbound 下面加 "streamSettings": { "network": "kcp" }
怀疑是GFW能检测到 tcp的vmess协议,直接把包给drop了。
能说的更详细一点吗?为什么传输层协议改成kcp居然没事,还有这是客户端还是服务器端的配置文件。你说的方法我还没有尝试,但看起来并不是很靠谱
我也碰到了,改了传输协议未kcp就莫名好了。inbound 下面加 "streamSettings": { "network": "kcp" } 怀疑是GFW能检测到 tcp的vmess协议,直接把包给drop了。
能说的更详细一点吗?为什么传输层协议改成kcp居然没事,还有这是客户端还是服务器端的配置文件。你说的方法我还没有尝试,但看起来并不是很靠谱
都要改,可以看这里。https://www.v2fly.org/config/transport/mkcp.html#kcpobject
可以提供一下配置文件(删除敏感信息),以及具体的服务器的位置么?
出问题的貌似都是vultr的服务器,具体表现就是ip正常,端口正常,所有的都正常,但网络不通。测试延迟会显示context deadline exceeded。换端口无用。应该是所有使用v2ray tcp模式的包全被精准识别然后丢掉了。
配置用的是tcp
可以提供一下配置文件(删除敏感信息),以及具体的服务器的位置么?
出问题的貌似都是vultr的服务器,具体表现就是ip正常,端口正常,所有的都正常,但网络不通。测试延迟会显示context deadline exceeded。换端口无用。应该是所有使用v2ray tcp模式的包全被精准识别然后丢掉了。
配置用的是tcp
这很难下定论,首先 Vultr 的服务器与大陆之间的路由本身并不友好,以及 Vultr 因为购买门槛低等原因导致其 IP 段很可能被 GFW 重点关注。如果 GFW 检测到无法识别的协议从大陆发送到 Vultr 机房,被丢包也并不是不可能。
需要一些试验数据来验证这些猜想是否成立。
怀疑是vultr被盯上了,所有相关软件版本都是最新 三个节点,西雅图和东南亚的几乎瘫痪,澳洲的目前仍可用(宽带:广东电信/广东移动) 若连移动的热点则均正常 早做准备吧,vultr支持国内支付方式,流量太多了
我是买 的阿里云新加坡的 轻量服务也不行
可以提供一下配置文件(删除敏感信息),以及具体的服务器的位置么? 配置和 zehuichen123 一样 服务器在新加坡
可以提供一下配置文件(删除敏感信息),以及具体的服务器的位置么?
出问题的貌似都是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后就正常了。
可以提供一下配置文件(删除敏感信息),以及具体的服务器的位置么?
出问题的貌似都是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。
遇到同样的问题,kcp 也没效
有解决了的兄弟顶一下哈
一台vultr的vps,前几天发生上面问题,测试vmess+tcp传输几乎秒封端口(nc测试time out),而且只封端口,不封ip,多久解封不清楚,反正再连再秒封。改用vmess+tcp+tls可以正常稳定连接,另外测试对于vless协议不存在这个问题,只用vless+tcp也不会有任何问题,可以正常稳定连接。所以个人认为可以确认vmess明码可以被精确定位打击。
偶尔能打开一个页面,很慢很慢,大家怎么解决的