v2ray-core icon indicating copy to clipboard operation
v2ray-core copied to clipboard

同一内网多v2ray客户端无法正常工作,分别放到不同内网中又恢复正常

Open xmurobi opened this issue 2 years ago • 4 comments

你正在使用哪个版本的 V2Ray?

4.45.2

你的使用场景是什么?

  1. 两台Mac,一台x64CPU,一台M1 MaxCPU,后者使用苹果的数据迁移服务迁移了所有数据
  2. 两台Mac现处于同一内网
  3. 两台Mac分别使用了x64版本和arm版本的4.45.2 v2ray作为客户端
  4. 两台Mac使用相同的v2ray配置,连接相同或不同的服务器

你看到的异常现象是什么?

  1. M1 Max这台只要切换服务器(两台使用不同的服务器集合切换),v2ray必导致系统崩溃,重启。
  2. 两台同时使用v2ray经常断流(不同服务器)。
  3. 经常出现[Warning] [289440955] app/proxyman/inbound: connection ends > proxy/http: connection ends > proxy/http: failed to write response > write tcp 127.0.0.1:8889->127.0.0.1:64439: write: protocol wrong type for socket
  4. 若其中一台离线,另外一台即可正常工作。
  5. M1 Max这台只要换到新的外网路由器下,所有功能均正常,不断流不崩溃,一切运行流畅

你期待看到的正常表现是怎样的?

两台机器在同一子网下都应该正常工作

请附上你的配置

服务端配置:

// 在这里附上服务器端配置文件

客户端配置:

// 在这里附上客户端配置
{
    "outbounds": [
        {
            "_QV2RAY_USE_GLOBAL_FORWARD_PROXY_": false,
            "mux": {
                "concurrency": 8,
                "enabled": true
            },
            "protocol": "vless",
            "sendThrough": "0.0.0.0",
            "settings": {
                "vnext": [
                    {
                        "address": "v2.xxx.com",
                        "port": 443,
                        "users": [
                            {
                                "encryption": "none",
                                "id": ""
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "ws",
                "security": "tls",
                "tlsSettings": {
                    "serverName": "v2.xxx.com"
                },
                "xtlsSettings": {
                    "serverName": "v2.xxx.com"
                }
            },
            "tag": "ServerA"
        }
    ]
}

请附上出错时软件输出的错误日志

服务器端错误日志:

// 在这里附上服务器端日志

客户端错误日志:

// 在这里附上客户端日志
2022/07/13 21:39:43 [Warning] [695311259] app/proxyman/inbound: connection ends > proxy/http: connection ends > proxy/http: failed to write response > write tcp 127.0.0.1:8889->127.0.0.1:64440: write: broken pipe
2022/07/13 21:39:43 [Warning] [556744874] app/proxyman/inbound: connection ends > proxy/http: connection ends > proxy/http: failed to write response > write tcp 127.0.0.1:8889->127.0.0.1:64454: write: broken pipe
2022/07/13 21:39:43 [Warning] [3578776640] app/proxyman/inbound: connection ends > proxy/http: connection ends > proxy/http: failed to write response > write tcp 127.0.0.1:8889->127.0.0.1:64465: write: broken pipe
2022/07/13 21:39:43 [Warning] [1447246522] app/proxyman/inbound: connection ends > proxy/http: connection ends > proxy/http: failed to write response > write tcp 127.0.0.1:8889->127.0.0.1:64470: write: broken pipe
2022/07/13 21:39:43 [Warning] [2144393108] app/proxyman/inbound: connection ends > proxy/http: connection ends > proxy/http: failed to write response > write tcp 127.0.0.1:8889->127.0.0.1:64536: write: protocol wrong type for socket
2022/07/13 21:39:43 [Warning] [2385527570] app/proxyman/inbound: connection ends > proxy/http: connection ends > proxy/http: failed to write response > write tcp 127.0.0.1:8889->127.0.0.1:64471: write: broken pipe

请附上访问日志

// 在这里附上服务器端日志

其它相关的配置文件(如 Nginx)和相关日志

如果 V2Ray 无法启动,请附上 --test 命令的输出

如果 V2Ray 服务运行异常,请附上 journal 日志

xmurobi avatar Jul 13 '22 14:07 xmurobi

我和你的情况类似,分流国内的经常时不时断流,反而国外的没事,排查了一圈还是没发现问题,目前怀疑是dns解析的问题。

raphael008 avatar Jul 14 '22 13:07 raphael008

@raphael008 我之前也有你这种情况,qv2ray中自定义了DNS还是无解。目前应该不是DNS问题。M1 Max这台,在有问题的网络中,另外一台x64的Mac使用一样的DNS独立使用,没有问题。而且,关闭这台x64的Mac,M1 Max问题一样存在,似乎在切换或者操作qv2ray的时候,v2ray无法被正常重启,提示某个端口被占用没有关闭。但是神奇的是,拿到我父母家,另外的网络,不同运营商,这台M1 Max的qv2ray和 v2ray就运行流畅,毫无问题。

xmurobi avatar Jul 15 '22 02:07 xmurobi

后续,在有问题的网络中,使用了shadowrocket, 同样的服务器客户端配置,问题就消失了。

xmurobi avatar Jul 15 '22 02:07 xmurobi

@xmurobi 我是有三台设备A,B,C,v2ray在A设备上,B/C设备浏览器直接socks代理到A上统一分流,现在我在B/C上分别先本地分流了,目前问题暂时解决了。 奇怪的是我看log里分流的策略都是正确的,每次断流的时候,日志里都没有新的打印出来。现在怀疑可能是触发了代码逻辑上的什么bug,当然dns的可能性还没排除。

raphael008 avatar Jul 15 '22 07:07 raphael008

This issue is stale because it has been open 120 days with no activity. Remove stale label or comment or this will be closed in 5 days

github-actions[bot] avatar Nov 13 '22 02:11 github-actions[bot]