search

v2fly / v2ray-core

A platform for building proxies to bypass network restrictions.
https://v2fly.org
MIT License
29.29k stars 4.63k forks source link

坐标广州，用移动4G连接亚马逊AWS搭建的新加坡VPS，V2RayNG app无法连接（VMess + WebSocket） #1844

Closed ytxmobile98 closed 2 years ago

ytxmobile98 commented 2 years ago

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

你的使用场景是什么？

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

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

请附上你的配置

服务端配置：

{
    "log": {
        "loglevel": "warning"
    },
    "routing": {
        "domainStrategy": "AsIs",
        "rules": [
            {
                "type": "field",
                "ip": [
                    "geoip:private"
                ],
                "outboundTag": "block"
            }
        ]
    },
    "inbounds": [
        {
            "listen": "0.0.0.0",
            "port": 1234,
            "protocol": "vmess",
            "settings": {
                "clients": [
                    {
                        "id": "{{ Generate a unique UUID using uuidgen }}"
                    }
                ]
            },
            "streamSettings": {
                "network": "ws",
                "security": "none"
            }
        },
        {
            "listen": "0.0.0.0",
            "port": 1235,
            "protocol": "vmess",
            "settings": {
                "clients": [
                    {
                        "id": "{{ Generate a unique UUID using uuidgen }}"
                    }
                ]
            },
            "streamSettings": {
                "network": "ws",
                "security": "none"
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "tag": "direct"
        },
        {
            "protocol": "blackhole",
            "tag": "block"
        }
    ]
}

客户端配置：

{
    "log": {
        "loglevel": "warning"
    },
    "routing": {
        "domainStrategy": "AsIs",
        "rules": [
            {
                "type": "field",
                "ip": [
                    "geoip:private"
                ],
                "outboundTag": "direct"
            }
        ]
    },
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": "1080",
            "protocol": "socks",
            "settings": {
                "auth": "noauth",
                "udp": true,
                "ip": "127.0.0.1"
            }
        },
        {
            "listen": "127.0.0.1",
            "port": "1080",
            "protocol": "http"
        }
    ],
    "outbounds": [
        {
            "protocol": "vmess",
            "settings": {
                "vnext": [
                    {
                        "address": "{{ AWS Server IP }}",
                        "port": 1235,
                        "users": [
                            {
                                "id": "{{ UUID, must match AWS server UUID }}"
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "ws"
            },
            "tag": "proxy"
        },
        {
            "protocol": "freedom",
            "tag": "direct"
        }
    ]
}

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

服务器端错误日志：

空白

客户端错误日志：

空白

请附上访问日志

空白

其它相关的配置文件（如 Nginx）和相关日志

亚马逊AWS入站规则： AWS入站规则

亚马逊AWS出站规则： AWS出站规则

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

N/A

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

无异常

canondin commented 2 years ago

"inbounds": [ { "listen": "127.0.0.1", "port": "1080", "protocol": "socks", "settings": { "auth": "noauth", "udp": true, "ip": "127.0.0.1" } }, { "listen": "127.0.0.1", "port": "1080", "protocol": "http" } ],

  1. 2 个协议端口不能设置一样的
  2. 跟服务端对一下
ytxmobile98 commented 2 years ago

尝试过了，不是端口问题。

我把http端口改成1081，移动4G还是连不上，而WiFi连接没问题。

图1：连接配置 V2Ray connection config

图2：V2RayNG设置 V2Ray settings

而且我试过在自己的笔记本电脑（系统：Ubuntu 22.04）上把HTTP和Socks都调到1080端口，用WiFi上被墙网站是可以的。

ytxmobile98 commented 2 years ago

再试了一下在移动4G下ping我的VPS。

安装https://url.cloud.huawei.com/hszToL1X3O 这个app，ping的结果正常。

Screenshot_20220627_122613_com huawei appmarket

Screenshot_20220627_122258

canondin commented 2 years ago

推荐用 x-ui 生成新的配置试试，我用了后，发现同样 vmess +ws ，xray 比 v2ray 快一点。

ytxmobile98 commented 2 years ago

推荐用 x-ui 生成新的配置试试，我用了后，发现同样 vmess +ws ，xray 比 v2ray 快一点。

是否需要修改streamSettings中的security，以及outbounds中的规则？

canondin commented 2 years ago

推荐用 x-ui 生成新的配置试试，我用了后，发现同样 vmess +ws ，xray 比 v2ray 快一点。

是否需要修改streamSettings中的security，以及outbounds中的规则？

集成好的，不用单独改其中的某一项

ytxmobile98 commented 2 years ago

推荐用 x-ui 生成新的配置试试，我用了后，发现同样 vmess +ws ，xray 比 v2ray 快一点。

开个X-ui重新配置了一遍，移动4G还是连不上。

服务器端配置：

{
    "log": null,
    "routing": {
        "rules": [
            {
                "inboundTag": [
                    "api"
                ],
                "outboundTag": "api",
                "type": "field"
            },
            {
                "ip": [
                    "geoip:private"
                ],
                "outboundTag": "blocked",
                "type": "field"
            },
            {
                "outboundTag": "blocked",
                "protocol": [
                    "bittorrent"
                ],
                "type": "field"
            }
        ]
    },
    "dns": null,
    "inbounds": [
        {
            "listen": "127.0.0.1",
            "port": 62789,
            "protocol": "dokodemo-door",
            "settings": {
                "address": "127.0.0.1"
            },
            "streamSettings": null,
            "tag": "api",
            "sniffing": null
        },
        {
            "listen": null,
            "port": 8388,
            "protocol": "vmess",
            "settings": {
                "clients": [
                    {
                        "id": "{{ Generate a unique UUID }}",
                        "alterId": 64
                    }
                ],
                "disableInsecureEncryption": false
            },
            "streamSettings": {
                "network": "ws",
                "security": "none",
                "wsSettings": {
                    "path": "/",
                    "headers": {}
                }
            },
            "tag": "inbound-8388",
            "sniffing": {
                "enabled": false,
                "destOverride": [
                    "http",
                    "tls"
                ]
            }
        },
        {
            "listen": null,
            "port": 8389,
            "protocol": "vmess",
            "settings": {
                "clients": [
                    {
                        "id": "{{ Generate a unique UUID }}",
                        "alterId": 64
                    }
                ],
                "disableInsecureEncryption": false
            },
            "streamSettings": {
                "network": "ws",
                "security": "none",
                "wsSettings": {
                    "path": "/",
                    "headers": {}
                }
            },
            "tag": "inbound-8389",
            "sniffing": {
                "enabled": false,
                "destOverride": [
                    "http",
                    "tls"
                ]
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "settings": {}
        },
        {
            "protocol": "blackhole",
            "settings": {},
            "tag": "blocked"
        }
    ],
    "transport": null,
    "policy": {
        "system": {
            "statsInboundDownlink": true,
            "statsInboundUplink": true
        }
    },
    "api": {
        "services": [
            "HandlerService",
            "LoggerService",
            "StatsService"
        ],
        "tag": "api"
    },
    "stats": {},
    "reverse": null,
    "fakeDns": null
}

在X-ui里面修改成这样： X-ui config

simplerick-simplefun commented 2 years ago

你的服务器端的log能看到客服端连接的信息吗？我估计8成看不到。 如果看不到的话，就说明被墙了。 你买个便宜的域名，ws上个tls和web前端，估计就能连上了。

ytxmobile98 commented 2 years ago

你的服务器端的log能看到客服端连接的信息吗？我估计8成看不到。 如果看不到的话，就说明被墙了。 你买个便宜的域名，ws上个tls和web前端，估计就能连上了。

试了一下用笔记本电脑和手机分别连接。

结果是：两者连接WiFi时在服务器的access.log中看到的全部为accepted记录；手机使用移动4G时看到的全部为rejected记录。

1. 清空原有的access.log记录，使用笔记本电脑访问https://www.google.com

未挂代理时的IP：120.235.191.62 来自：中国广东广州天河区 移动

打开Google网站后，access.log内容：

ubuntu@ip-172-31-27-98:/var/log/xray$ sudo cat access.log
2022/07/02 13:38:17 120.235.191.62:2032 accepted tcp:firefoxusercontent.com:443
2022/07/02 13:38:17 120.235.191.62:2160 accepted tcp:www.google.com:443
2022/07/02 13:38:17 120.235.191.62:2236 accepted tcp:www.google.com:443
2022/07/02 13:38:18 120.235.191.62:2064 accepted tcp:www.google.com:443
2022/07/02 13:38:18 120.235.191.62:2176 accepted tcp:www.google.com:443
2022/07/02 13:38:21 127.0.0.1:58570 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:38:21 120.235.191.62:2338 accepted tcp:www.google.com:443
2022/07/02 13:38:21 120.235.191.62:2270 accepted tcp:www.gstatic.com:443
2022/07/02 13:38:22 120.235.191.62:2120 accepted tcp:apis.google.com:443

2. 再次清空access.log，使用手机连上WiFi并访问https://facebook.com

未挂代理时的IP：120.235.191.62 来自：中国广东广州天河区 移动

2.1 先在V2RayNG测试连接延迟

先清空access.log。

然后在V2RayNG里面启用自己VPS配置好的节点，测试延迟。

测试完后在access.log看到以下内容：

ubuntu@ip-172-31-27-98:/var/log/xray$ sudo cat access.log
2022/07/02 13:39:31 127.0.0.1:58584 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:39:41 127.0.0.1:58586 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:39:47 120.235.191.62:2148 accepted tcp:olime.baidu.com:80
2022/07/02 13:39:51 127.0.0.1:58588 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:39:52 120.235.191.62:2386 accepted tcp:olime.baidu.com:80
2022/07/02 13:40:00 120.235.191.62:2072 accepted tcp:1.1.1.1:853
2022/07/02 13:40:00 120.235.191.62:2134 accepted tcp:80.158.45.160:5223
2022/07/02 13:40:01 127.0.0.1:58590 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:40:01 120.235.191.62:2094 accepted tcp:1.1.1.1:853
2022/07/02 13:40:01 120.235.191.62:2148 accepted tcp:mtalk.google.com:5228
2022/07/02 13:40:02 120.235.191.62:2126 accepted tcp:dns.weixin.qq.com.cn:8080
2022/07/02 13:40:03 120.235.191.62:2072 accepted tcp:extshort.weixin.qq.com:80
2022/07/02 13:40:03 120.235.191.62:2372 accepted tcp:www.google.com:80
2022/07/02 13:40:04 120.235.191.62:2064 accepted tcp:203.205.253.214:80
2022/07/02 13:40:07 120.235.191.62:2246 accepted tcp:91.108.56.191:80
2022/07/02 13:40:07 120.235.191.62:2068 accepted tcp:91.108.56.191:80
2022/07/02 13:40:07 120.235.191.62:2264 accepted tcp:91.108.56.191:443
2022/07/02 13:40:07 120.235.191.62:2192 accepted tcp:91.108.56.191:443
2022/07/02 13:40:07 120.235.191.62:2108 accepted tcp:91.108.56.191:443
2022/07/02 13:40:07 120.235.191.62:2100 accepted tcp:91.108.56.191:80

2.2 清空access.log，并尝试访问Facebook

使用Android版Chrome浏览器打开Facebook网站后，access.log内容：

ubuntu@ip-172-31-27-98:/var/log/xray$ sudo cat access.log
2022/07/02 13:42:11 127.0.0.1:58622 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:42:21 127.0.0.1:58624 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:42:23 120.235.191.62:2142 accepted tcp:minorshort.weixin.qq.com:80
2022/07/02 13:42:24 120.235.191.62:2132 accepted tcp:1.1.1.1:853
2022/07/02 13:42:24 120.235.191.62:2158 accepted tcp:www.google.com.hk:443
2022/07/02 13:42:24 120.235.191.62:2430 accepted udp:221.179.38.7:53
2022/07/02 13:42:24 120.235.191.62:2414 accepted udp:221.179.38.7:53
2022/07/02 13:42:24 120.235.191.62:2144 accepted udp:221.179.38.7:53
2022/07/02 13:42:24 120.235.191.62:2058 accepted tcp:chrome.cloudflare-dns.com:443
2022/07/02 13:42:24 120.235.191.62:2182 accepted tcp:chrome.cloudflare-dns.com:443
2022/07/02 13:42:25 120.235.191.62:2344 accepted tcp:chrome.cloudflare-dns.com:443
2022/07/02 13:42:25 120.235.191.62:2224 accepted tcp:www.google.com:443
2022/07/02 13:42:25 120.235.191.62:2156 accepted tcp:beacons.gcp.gvt2.com:443
2022/07/02 13:42:25 120.235.191.62:2080 accepted tcp:beacons.gcp.gvt2.com:443
2022/07/02 13:42:25 120.235.191.62:2192 accepted tcp:beacons.gcp.gvt2.com:443
2022/07/02 13:42:25 120.235.191.62:2118 accepted tcp:beacons.gcp.gvt2.com:443
2022/07/02 13:42:25 120.235.191.62:2416 accepted udp:74.125.200.94:443
2022/07/02 13:42:26 120.235.191.62:2072 accepted tcp:play.googleapis.com:443
2022/07/02 13:42:26 120.235.191.62:2220 accepted tcp:play.googleapis.com:443
2022/07/02 13:42:28 120.235.191.62:2354 accepted udp:157.240.13.35:443
2022/07/02 13:42:28 120.235.191.62:2168 accepted tcp:incoming.telemetry.mozilla.org:443
2022/07/02 13:42:31 127.0.0.1:58628 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:42:37 120.235.191.62:2404 accepted tcp:facebook.com:443
2022/07/02 13:42:37 120.235.191.62:2136 accepted tcp:facebook.com:443
2022/07/02 13:42:37 120.235.191.62:2378 accepted tcp:optimizationguide-pa.googleapis.com:443
2022/07/02 13:42:39 120.235.191.62:2090 accepted tcp:kaios-d.facebook.com:443
2022/07/02 13:42:39 120.235.191.62:2114 accepted udp:157.240.13.19:443
2022/07/02 13:42:40 120.235.191.62:2154 accepted udp:157.240.7.26:443
2022/07/02 13:42:40 120.235.191.62:2054 accepted udp:157.240.235.1:443
2022/07/02 13:42:40 120.235.191.62:2420 accepted udp:157.240.15.13:443
2022/07/02 13:42:41 127.0.0.1:58630 accepted tcp:127.0.0.1:0 [api -> api]

3. 手机上切到移动数据连接（此时连接失败）

未挂代理时的IP：223.104.1.254 来自：中国广东 移动

再次清空access.log。直接在V2RayNG里测试延迟，提示信息是“失败：context deadline exceeded”及“失败：io: read/write on closed pipe”（两者会交替出现）。

access.log内容：

ubuntu@ip-172-31-27-98:/var/log/xray$ sudo cat access.log
2022/07/02 13:46:46 120.197.197.31:34398 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:46 120.197.197.31:34415 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:46 120.197.197.31:34414 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:46 120.197.197.31:34416 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:46 120.197.197.31:34449 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:46 120.197.197.31:34456 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:46 120.197.197.31:34462 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:46 120.197.197.31:34467 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:46 120.197.197.31:34499 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:47 120.197.197.31:34569 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:48 120.197.197.31:34900 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:51 127.0.0.1:58688 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:46:51 120.197.197.31:35444 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:52 120.197.197.31:35635 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:55 120.197.197.31:35972 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:55 120.197.197.31:36013 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:57 120.197.197.31:36339 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:58 120.197.197.31:35918 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:46:58 120.197.197.31:34536 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:46:59 120.197.197.31:36667 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:01 127.0.0.1:58690 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:47:01 120.197.197.31:25621 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:01 120.197.197.31:36964 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:01 120.197.197.31:25786 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:02 120.197.197.31:25862 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:02 120.197.197.31:26565 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:03 120.197.197.31:26666 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:03 120.197.197.31:26203 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:04 120.197.197.31:36823 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:06 120.197.197.31:37131 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:06 120.197.197.31:37134 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:07 120.197.197.31:37303 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:08 120.197.197.31:38117 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:09 120.197.197.31:27288 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:09 120.197.197.31:27434 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:10 120.197.197.31:27511 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:10 120.197.197.31:38487 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:10 120.197.197.31:36801 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:11 127.0.0.1:58694 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:47:11 120.197.197.31:27703 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2022/07/02 13:47:12 120.197.197.31:38115 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:14 120.197.197.31:38433 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:16 120.197.197.31:39507 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:16 120.197.197.31:39506 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:16 120.197.197.31:38836 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:18 120.197.197.31:39883 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:19 120.197.197.31:39399 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:20 120.197.197.31:40215 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:20 120.197.197.31:40260 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:21 127.0.0.1:58696 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:47:23 120.197.197.31:40668 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:25 120.197.197.31:40446 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:27 120.197.197.31:41243 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:27 120.197.197.31:40696 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:28 120.197.197.31:41416 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:29 120.197.197.31:40992 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:30 120.197.197.31:41707 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:31 127.0.0.1:58698 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:47:31 120.197.197.31:41819 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:32 120.197.197.31:41903 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:34 120.197.197.31:42278 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:35 120.197.197.31:42399 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:36 120.197.197.31:42538 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:37 120.197.197.31:42702 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:37 120.197.197.31:42732 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:38 120.197.197.31:42893 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:39 120.197.197.31:43057 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:40 120.197.197.31:43119 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:41 127.0.0.1:58700 accepted tcp:127.0.0.1:0 [api -> api]
2022/07/02 13:47:41 120.197.197.31:43409 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:42 120.197.197.31:43537 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:44 120.197.197.31:43807 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:44 120.197.197.31:43961 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:44 120.197.197.31:43990 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:45 120.197.197.31:44119 rejected  proxy/vmess/encoding: failed to read request header > websocket: unexpected reserved bits 0x40
2022/07/02 13:47:47 120.197.197.31:35288 rejected  proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF

同时尝试了用Termius，在移动4G网络下连接到VPS上的SSH，是能打开，但是一次需要等待5-6秒钟（比WiFi慢）。

这是连接后看到的终端画面： Screenshot_20220702_215657_com server auditor ssh client

simplerick-simplefun commented 2 years ago

我说的是你服务端的log。你发的这些都是客户端的log啊。 服务端的log不是你电脑或手机上的，是你新加坡vps上面的。 就是你服务器上的v2ray生成的log，重点是error.log。 我建议你把所有的log都清了，把两个端的loglevel都改成debug，然后重新连接一次，然后把服务端客户端的access.log 和 error.log一共4个文件都上传上来。 我的猜测是你服务端要不根本没收到客户端的连接，要不就是连接有问题服务端不接收。 还有一个问题你检查一下，你aws新加坡vps的相应端口有没有打开。aws要手动打开端口的，不然你客户端到服务端的连接都会被防火墙挡住。

ytxmobile98 commented 2 years ago

我说的是你服务端的log。你发的这些都是客户端的log啊。 服务端的log不是你电脑或手机上的，是你新加坡vps上面的。 就是你服务器上的v2ray生成的log，重点是error.log。

这几个都是SSH连到VPS后在上面看到的log。

ubuntu@ip-172-31-27-98这个就是服务器端的命令提示符。

simplerick-simplefun commented 2 years ago

我说的是你服务端的log。你发的这些都是客户端的log啊。 服务端的log不是你电脑或手机上的，是你新加坡vps上面的。 就是你服务器上的v2ray生成的log，重点是error.log。

这几个都是SSH连到VPS后在上面看到的log。

ubuntu@ip-172-31-27-98这个就是服务器端的命令提示符。

这么说的话，客户端已经连上了服务端，服务端也接收了请求。现在就是从服务端接受请求开始，服务端自己获取目标网络信息、获取之后返还给客户端 这两步有可能出问题。 具体需要看一下两边的error.log，但是感觉更可能是返还客户端这一块出问题了。如果是这样的话那就是特定流量被墙了。

WordsWorthLess commented 2 years ago

沒有用過AWS，我猜應該是防火牆的問題，看看有沒有放行443，ufw allow 443，或者 firewall-cmd —permanent —zone=public —add-port=443/tcp, 也有可能是iptables 過濾了，還要看一下控制台有沒有防火牆規則，反正我用甲骨文就是這問題

simplerick-simplefun commented 2 years ago

我又仔细看了一下这个issue。wifi下可以连接，移动4G不能连接。服务端提示failed to read request header > websocket: unexpected reserved bits 0x40。 说明就是客户端通过移动4G连接服务端的流量被墙了。 这个不太可能通过v2ray的软件更新来解决；题主的配置也过于简单了，就是用websocket直接传送vmess流量。而vmess能够被识别指纹这是几年的事情了。而移动的网络是墙中之墙这也是有名的。现在大家通行的做法都是至少加一层tls，里面倒是可以不用vmess，用vless。 最保险的就是web服务器（nginx/caddy）做前端，架设真实的网站，接收v2ray的流量，并且解开tls，再传给后端的v2ray。这种配置是最不容易被墙的。 所以这里只能建议更新配置。可以参考这里：https://guide.v2fly.org/advanced/wss_and_web.html

ytxmobile98 commented 2 years ago

我又仔细看了一下这个issue。wifi下可以连接，移动4G不能连接。服务端提示failed to read request header > websocket: unexpected reserved bits 0x40。 说明就是客户端通过移动4G连接服务端的流量被墙了。 这个不太可能通过v2ray的软件更新来解决；题主的配置也过于简单了，就是用websocket直接传送vmess流量。而vmess能够被识别指纹这是几年的事情了。而移动的网络是墙中之墙这也是有名的。现在大家通行的做法都是至少加一层tls，里面倒是可以不用vmess，用vless。 最保险的就是web服务器（nginx/caddy）做前端，架设真实的网站，接收v2ray的流量，并且解开tls，再传给后端的v2ray。这种配置是最不容易被墙的。 所以这里只能建议更新配置。可以参考这里：https://guide.v2fly.org/advanced/wss_and_web.html

新的尝试：使用VMess WebSocket + TLS配置连接成功。

X-UI配置： X-UI VMess WebSocket + TLS

V2RayNG设置： Screenshot_20220710_145436_edit_15821104709564

此时已经可以打开被墙网站。（但是移动4G下速度稍慢些） Screenshot_20220710_150002_com android chrome

Agumon2012 commented 2 years ago

hello, 我是5月就参考 https://guide.v2fly.org/advanced/wss_and_web.html 这个配置的服务端和客户端，坐标上海 联通5G，此前5G或wifi都能正常使用。大概也是上个月开始5G就上不了网了，手机 iPhone，客户端 Shadowrocket. 切换为 wifi 就可以。 此外，我在 mac 电脑上分别用了 clashX 和 shadowrocket 的客户端，相同的配置，家里wifi可以正常使用，使用iPhone 手机分享的热点也不能上网。 此外，我用小米k40安卓机安装 v2rayNG 客户端，使用 iphone 分享的热点却可以上网。 @simplerick-simplefun 大佬能帮忙分析一下吗~

feipinxiang commented 2 years ago

前几天遇到的仅供参考：vps ssh访问正常，v2r配置nginx+tls+ws，公司网络为插手机卡的CPE（相当于5g热点），手机4G。win+v2rayN连CPE怎么都连不上，Android+CPE+v2rayng不正常，Android+自己卡4g+v2rayng正常。后来重启CPE后连接正常，所以判断不是客户端或服务器的问题，而是本身移动互联网某些线路有问题，后面又有两次这样的情况都是重启CPE（相当于重连了一下5G网络）解决的。

Agumon2012 commented 2 years ago

看来防火墙又加高了

simplerick-simplefun commented 2 years ago

hello, 我是5月就参考 https://guide.v2fly.org/advanced/wss_and_web.html 这个配置的服务端和客户端，坐标上海 联通5G，此前5G或wifi都能正常使用。大概也是上个月开始5G就上不了网了，手机 iPhone，客户端 Shadowrocket. 切换为 wifi 就可以。 此外，我在 mac 电脑上分别用了 clashX 和 shadowrocket 的客户端，相同的配置，家里wifi可以正常使用，使用iPhone 手机分享的热点也不能上网。 此外，我用小米k40安卓机安装 v2rayNG 客户端，使用 iphone 分享的热点却可以上网。 @simplerick-simplefun 大佬能帮忙分析一下吗~

试试你服务器上搭建的网站能否不挂梯子裸连正常访问，能访问应该就能用梯子。用你梯子出问题的设备/模式去试。不能访问就是被墙了。因为你用家庭wifi可以访问梯子，假设你家庭wifi没有魔改，就说明你的梯子/服务器/域名不是被GFW墙的，而是被运营商设置的策略墙的。这种被墙一般不是长时间的，而且具体墙的是什么（DNS污染/服务器IP/特定端口/域名）都有可能。

@feipinxiang 你遇到的应该就是这种。重启会重新换IP，说明你那个运营商策略自动墙你的起始IP到梯子IP这一段。如果可能优化下配置，看看是不是哪里模拟正常web访问不像。实在不行可以加挂CDN cloudflare，这样你公司访问CDN的IP，肯定不会被墙，就是速度慢一些。然后原本能正常连接的就正常连接。你总是被运营商的墙判定为疑似梯子也不好，时间长了容易被GFW墙。

@Agumon2012 你的这个情况，如果确实是小米k40使用iphone分享的5G热点可以用梯子，而iphone自己本身不行，那么最可能的是dns污染导致。你的iphone连接梯子时被运营商DNS污染成错误的IP，而小米K40有设置使用另外的的DNS服务所以梯子域名没被污染。但是这种情况发生的可能性太低了，我建议你再仔细确认下。一个简单的修复/测试是iphone/mac客户端设置的服务器地址从域名改成IP。如果你之前就是IP，那就说明你反馈的情况哪里不真实，需要你再确认。

Agumon2012 commented 2 years ago

@simplerick-simplefun 感谢大佬~

  1. 我一直用的 cloudfare 的域名访问的，A记录配置 xx.com 二级域名指定ip，A记录配置的二级域名从未直接使用过；C记录配置 xx.xx.com 代理 xx.com，v2ray 一直都是访问 xx.xx.com 这个三级域名；
  2. 确实是小米k40 用iPhone的5G热点可以访问，但是比直接连家里的wifi慢；
  3. 此外在 iphone 上的 shadowrocket 客户端做连通性测试是通的，延迟200-300ms 左右正常范围
  4. iPhone浏览器直接访问 xx.xx.com 失败，应该是这个3级域名被墙了，但是第2点确实很难说通

----------分割线----------

  1. 刚刚又试了一下，访问v2ray 的三级域名切换为 yy.xx.com 仍然访问失败
  2. 补充说明，小米 k40 是电信，iphone用的联通卡
simplerick-simplefun commented 2 years ago

@simplerick-simplefun 感谢大佬~

  1. 我一直用的 cloudfare 的域名访问的，A记录配置 xx.com 二级域名指定ip，A记录配置的二级域名从未直接使用过；C记录配置 xx.xx.com 代理 xx.com，v2ray 一直都是访问 xx.xx.com 这个三级域名；
  2. 确实是小米k40 用iPhone的5G热点可以访问，但是比直接连家里的wifi慢；
  3. 此外在 iphone 上的 shadowrocket 客户端做连通性测试是通的，延迟200-300ms 左右正常范围
  4. iPhone浏览器直接访问 xx.xx.com 失败，应该是这个3级域名被墙了，但是第2点确实很难说通

----------分割线---------- 5. 刚刚又试了一下，访问v2ray 的三级域名切换为 yy.xx.com 仍然访问失败 6. 补充说明，小米 k40 是电信，iphone用的联通卡

1.有没有尝试客户端填写服务器地址从域名改为IP？传输方式那里不要改，只是改server address。 2.我看你的描述感觉可能哪里配置有问题。建议把全部配置发上来看一下。服务端nginx/caddy+v2，cloudflare，客户端配置。 这里面，第一你的服务器上的前端是哪个？如果使用v2fly一般前端是nginx/caddy，然后根据三级域名或域名后的访问地址分流。如果你基于三级域名分流，nginx接受入站域名 x1.xx.com xx.com x2.xx.com，而x1.xx.com会分流到v2fly，那么正常浏览器只能访问xx.com x2.xx.com。如果你基于path分流，nginx接受入站域名 x1.xx.com xx.com x2.xx.com，那么这三个都可以网页访问，而x1.xx.com/v2pth/ xx.com/v2pth/ x2.xx.com/v2pth/ 会分流给v2fly。 然后你用的CF，是只使用CF作为域名解析，还是使用了CF的CDN功能。如果涉及CDN，就还要看CF的配置情况，证书是怎么配置的，是不是CF和服务器都有相同证书，等等。 可能性太多。 如果证书配置没有问题，那么应该CF的代理IP和原始服务器IP都可以作为v2的服务器地址来使用。

另外，我其实推荐不适用CF的CDN来中继/代理。因为CF CDN只能解决梯子ip被墙的问题，但是不能解决域名阻断。如果你整体配置没有问题，那么目前vmess/vless/trojan/trojan-go/naiveproxy等等这些都是隐蔽性很高无法被墙进行数据包识别的。然后墙就只能去以境内单一或少数ip对境外固定网站进行日常大流量访问这种疑似的情况去墙。这种墙如果加入了sni域名阻断，那么CF CDN也是无用的。除非你用的是一个ip已经被墙的服务器，用CF套ip代理来起死回生，那还有意义。否则CF CDN只能降低连接质量减低网速。

Agumon2012 commented 2 years ago

  1. 我是基于path分流的；电脑上 x1.xx.com xx.com x2.xx.com 都可以访问到 nginx 的默认页面；其中x1和x2 配置了基于path的v2ray; 手机流量三个域名都不能访问；

  2. CF 配置如下 image

  3. 证书都是 acme 申请的证书，都是在 nginx 上配置的：

server { listen 443 ssl; ssl on; ssl_certificate /root/ca/v2ray/v2ray_uni.crt; ssl_certificate_key /root/ca/v2ray/v2ray_uni.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; server_name uni.xx.top; location /xxxxpath { #与 V2Ray 配置中的 path 保持一致 proxy_redirect off; proxy_pass http://127.0.0.1:30001; # WebSocket 监听在环回地址的端口 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $http_host;

# Show realip in v2ray access.log
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

} }

Agumon2012 commented 2 years ago

所以结论应该是 我这个域名 被联通强了吧

simplerick-simplefun commented 2 years ago

所以结论应该是 我这个域名 被联通强了吧

一般会认为你手机的流量网络墙了这个梯子，但是既然你用红米k40连接iphone的流量热点可以用梯子，就说明不是墙而是其他的因素。这里你可以用红米k40连接iphone的流量热点试一下，应该x1.xx.com xx.com x2.xx.com三个域名都可以在红米k40上打开。 那么我倾向于认为是（基于某种原因）iphone上面的域名解析被污染了，而红米k40没有。 这里你直接在iphone梯子客户端填写ip，不要填写域名，应该就能用了。具体的办法是，用你的电脑cmd ping一下xx.com，或者百度一下dns解析，随便找个国内的服务解析一下你的域名得到ip，应该就能得到CF的中继/代理ip了。然后在服务器地址项填写这个IP（而不是域名），其他不变。

  "outbounds": [
    {
      "protocol": "xxxx",
      "settings": {
        "vnext": [
          {
            "address": "填写IP",
            "port": 443,
            "users": [

另外你也可以分别在iphone和红米上安装个ping功能的应用，分别ping一下xx.com，我觉得应该会给出不同的ip。

ytxmobile98 commented 2 years ago

所以结论应该是 我这个域名 被联通强了吧

一般会认为你手机的流量网络墙了这个梯子，但是既然你用红米k40连接iphone的流量热点可以用梯子，就说明不是墙而是其他的因素。这里你可以用红米k40连接iphone的流量热点试一下，应该x1.xx.com xx.com x2.xx.com三个域名都可以在红米k40上打开。 那么我倾向于认为是（基于某种原因）iphone上面的域名解析被污染了，而红米k40没有。 这里你直接在iphone梯子客户端填写ip，不要填写域名，应该就能用了。具体的办法是，用你的电脑cmd ping一下xx.com，或者百度一下dns解析，随便找个国内的服务解析一下你的域名得到ip，应该就能得到CF的中继/代理ip了。然后在服务器地址项填写这个IP（而不是域名），其他不变。

  "outbounds": [
    {
      "protocol": "xxxx",
      "settings": {
        "vnext": [
          {
            "address": "填写IP",
            "port": 443,
            "users": [

另外你也可以分别在iphone和红米上安装个ping功能的应用，分别ping一下xx.com，我觉得应该会给出不同的ip。

如果你域名托管在Cloudflare上的话，应该要把proxy status设定为DNS only才行。

https://developers.cloudflare.com/dns/manage-dns-records/reference/proxied-dns-records/