Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

关于传输协议 gRPC 的一些疑惑,望解答。 #975

Closed
ghost opened this issue Mar 7, 2022 · 74 comments
Closed

关于传输协议 gRPC 的一些疑惑,望解答。 #975

ghost opened this issue Mar 7, 2022 · 74 comments

Comments

@ghost
Copy link

ghost commented Mar 7, 2022

最近看到一个关于主动探测“23 3 3”相关的 issue ,在社区目前还未有结论时,想先暂时切换到 gRPC 模式使用。但现在有几个疑问如下,望大家解惑。

问题 1:gRPC 模式下带宽跑不起来

首先不得不说 gRPC 传输协议相比其他协议,握手响应是真滴快!无论什么多图多元素的页面,基本都是秒开。有时恍惚了还以为在使用 IPLC 节点忘记换了。不过遇到了也是唯一的个问题——带宽跑不起来。

有两条线路,分别是电信 500Mb/30Mb 宽带与移动 200Mb 专线,服务器位于美西电信 CN2 GIA 机房。使用 VLESS+xTLS 、 VLESS+TLS 或 VLESS+TLS+WebSocket 时,均能跑满上下行带宽。但是切换到 gRPC 模式后,下行在 50Mb 左右,上行在 5Mb 左右。虽说日常上网看视频什么的足够了,但是觉得这样的带宽表现肯定是“不正常”的。

服务端的配置试过 Nginx:443 --> Xray(gRPC) --> free
也试过配置 Xray:443 --> Nginx --> Xray(gRPC) --> free

但是没什么区别,还是一样的情况。感觉应该是 Nginx 的配置问题(接下来排查的方向)。

问题 2 :关于 Nginx 的配置(已解决)

如果不使用 Xray-examples gRPC 配置范例中推荐的 Nginx 参数及值(如下),而使用默认值或其他值时,是否会影响到 gRPC 传输协议工作时的带宽表现?

server {
   listen ... so_keepalive=on;

   client_header_timeout 1071906480m;
   keepalive_timeout 1071906480m;

   location /gRPC_name {
        client_max_body_size 0;
        client_body_timeout 1071906480m;
        grpc_read_timeout 1071906480m;
        grpc_pass ...
    }
}

我的 Nginx 服务器预设值

client_header_timeout 10;
keepalive_timeout 65;
client_max_body_size 8M;
client_body_timeout 10;

问题 3 :普通模式与 Multi 模式的区别(已解决)

官方文档 GRPCObject 里只提到了“Multi 模式”比“普通模式”有一定的性能提升,但没有描述两者工作方式的差异。希望有人能用几句话简单概括下两者工作方式有什么不同,感谢!

官方文档中提到了使用 Nginx 作反向代理时,普通模式与 Multi 模式需要使用不同的 location path 设置:
普通模式:

    location /gRPC_name/Tun {
        grpc_pass ...;
    }

Multi 模式

    location /gRPC_name/TunMulti {
        grpc_pass ...;
    }

但实际使用中发现 location path 设置为 /gRPC_name 也能工作,想知道其中的具体区别。

    location /gRPC_name {
        grpc_pass ...;
    }

另外,还想再确认下:

  • 使用 gRPC 的普通模式时,是否 client.json 中的 "multiMode": false 、 nginx.conf 中的 location /gRPC_name/Tunserver.json 中的 "multiMode": false 三者缺一不可?
  • 使用 gRPC 的 Multi 模式时,是否 client.json 中的 "multiMode": true 、 nginx.conf 中的 location /gRPC_name/TunMultiserver.json 中的 "multiMode": true 三者缺一不可?

目前的配置

client.json

{
    "outbounds": [
        {
            "protocol": "vless",
            "settings": {
                "vnext": [
                    {
                        "address": "xxx.com",
                        "port": 443,
                        "users": [
                            {
                                "id": "UUID-UUID-UUID-UUID",
                                "encryption": "none"
                            }
                        ]
                    }
                ]
            },
            "streamSettings": {
                "network": "grpc",
                "security": "tls",
                "grpcSettings": {
                    "serviceName": "gRPC_name",
                    "multiMode": true
                }
            }
        }
    ]
}

server.json

{
    "inbounds": [
        {
            "port": 443,
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "UUID-UUID-UUID-UUID"
                    }
                ],
                "decryption": "none",
                "fallbacks": [
                    {
                        "alpn": "h2",
                        "dest": "/.../h2c.sock",
                        "xver": 1
                    },
                    {
                        "dest": "/.../default.sock",
                        "xver": 1
                    }
                ]
            },
            "streamSettings": {
                "network": "tcp",
                "security": "tls",
                "tlsSettings": {
                    "alpn": [
                        "h2",
                        "http/1.1"
                    ],
                    "certificates": [
                        {
                            "certificateFile": "/.../xxx.com.crt",
                            "keyFile": "/.../xxx.com.key"
                        }
                    ]
                }
            }
        },
        {
            "listen": "/.../grpc.sock",
            "protocol": "vless",
            "settings": {
                "clients": [
                    {
                        "id": "UUID-UUID-UUID-UUID"
                    }
                ],
                "decryption": "none"
            },
            "streamSettings": {
                "network": "grpc",
                "grpcSettings": {
                    "serviceName": "gRPC_name",
                    "multiMode": true
                }
            }
        }
    ]
}

nginx.conf

server {
    listen unix:/.../default.sock proxy_protocol;
    listen unix:/.../h2c.sock http2 proxy_protocol;

    server_name xxx.com;

    # reverse proxy for gRPC
    location /gRPC_name/TunMulti {
        grpc_pass unix:/.../grpc.sock;
    }

    ... ...
}
@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

client_max_body_size 不设 0 连接会意外关闭。比如 浏览器下载文件

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

grpc_read_timeout 不设较大值 Nginx error.log 会有 timeout

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

client_header_timeout & keepalive_timeout & client_body_timeout 不设较大值,如果 没有数据传输 连接会在 60/75秒 时关闭,客户端会重新连接,反复。

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

关于部分线路 gRPC 过 Nginx 后 降速问题 可能的原因。
可能是因为 Ngimx 不回复 大量的 h2 ping,而 线路差 需要一直调窗口大小,而调 窗口大小 需要 h2 ping。

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

location 默认是 模糊匹配。
location = 是全字匹配。

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

multiMode 默认是 false 即 普通模式( Tun

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

关于部分线路 gRPC 过 Nginx 后 降速问题 可能的原因。
可能是因为 Ngimx 不回复 大量的 h2 ping,而 线路差 需要一直调窗口大小,而调 窗口大小 需要 h2 ping。

可以尝试不经过 Nginx。

@ghost
Copy link
Author

ghost commented Mar 7, 2022

client_header_timeout & keepalive_timeout & client_body_timeout 不设较大值,如果 没有数据传输 连接会在 60/75秒 时关闭,客户端会重新连接,反复。

@xqzr 非常感谢你的回复。 Nginx 服务器有在跑正常 Web 业务,如下的 nginx.conf 参数如果设置为 官方 gRPC 配置范例 中的推荐值 1071906480m ,担心会引起一些不可预知的问题。比如正常的 Web 会话无法及时释放、加重服务器负载之类的。

    client_body_timeout 3600;
    client_header_timeout 3600;
    client_max_body_size 0;
    keepalive_timeout 3600;

考虑到正常 Web 业务与“科学”上网兼顾的话,将超时阈值设置为 1 小时,根据您的经验,这样会不会有改善或者还需要设置更大的值?

location 默认是 模糊匹配。 location = 是全字匹配。

谢谢,明白了。

multiMode 默认是 false 即 普通模式( Tun

gRPC 传输协议要使用性能更好“Multi 模式”,配置是否应该是这样?
client.json > "multiMode": true
nginx.conf > location /gRPC_name/TunMulti or location = /gRPC_name/TunMulti
server.json > "multiMode": true

关于部分线路 gRPC 过 Nginx 后 降速问题 可能的原因。
可能是因为 Ngimx 不回复 大量的 h2 ping,而 线路差 需要一直调窗口大小,而调 窗口大小 需要 h2 ping。

可以尝试不经过 Nginx。

担心 gRPC 服务存在被主动探测的风险。

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

gRPC 传输协议要使用性能更好“Multi 模式”,配置是否应该是这样? client.json > "multiMode": true nginx.conf > location /gRPC_name/TunMulti or location = /gRPC_name/TunMulti server.json > "multiMode": true

location /gRPC_name 即可兼容两种模式

@ghost
Copy link
Author

ghost commented Mar 7, 2022

gRPC 传输协议要使用性能更好“Multi 模式”,配置是否应该是这样? client.json > "multiMode": true nginx.conf > location /gRPC_name/TunMulti or location = /gRPC_name/TunMulti server.json > "multiMode": true

location /gRPC_name 即可兼容两种模式

(๑•̀ㅂ•́)و✧❤

再多问一句,"multiMode": true 是客户端与服务端都需要设置,还是说服务端自适应(可以不用设置)?

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

担心 gRPC 服务存在被主动探测的风险。

临时试一下 没事的吧

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

@xqzr 非常感谢你的回复。 Nginx 服务器有在跑正常 Web 业务,如下的 nginx.conf 参数如果设置为 官方 gRPC 配置范例 中的推荐值 1071906480m ,担心会引起一些不可预知的问题。比如正常的 Web 会话无法及时释放、加重服务器负载之类的。

    client_body_timeout 3600;
    client_header_timeout 3600;
    client_max_body_size 0;
    keepalive_timeout 3600;

考虑到正常 Web 业务与“科学”上网兼顾的话,将超时阈值设置为 1 小时,根据您的经验,这样会不会有改善或者还需要设置更大的值?

可以尝试新值
https://github.com/XTLS/Xray-examples/blob/97af2eb5ef019b873b899db83ed58f83f8a9796e/VLESS-GRPC/README.md#nginx

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

再多问一句,"multiMode": true 是客户端与服务端都需要设置,还是说服务端自适应(可以不用设置)?

仅 客户端

@ghost
Copy link
Author

ghost commented Mar 7, 2022

担心 gRPC 服务存在被主动探测的风险。

临时试一下 没事的吧

刚才试了下服务端不通过 Nginx 反代而直接监听 443 端口,下行带宽没什么变化还是 50Mb 左右。不过上行带宽提高了,也到 50Mb 左右。看来终端到服务器的 CN2 GIA 线路上使用 gRPC 协议也只能这样子了。

再多问一句,"multiMode": true 是客户端与服务端都需要设置,还是说服务端自适应(可以不用设置)?

仅 客户端

明白了,谢谢。

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

听说 client_body_buffer_size 调大 可以提升 上传速率,可以试试 设为 512k
https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size

@ghost
Copy link
Author

ghost commented Mar 7, 2022

听说 client_body_buffer_size 调大 可以提升 上传速率,可以试试 设为 512k https://nginx.org/en/docs/http/ngx_http_core_module.html#client_body_buffer_size

o( ̄▽ ̄)d 上行速度提升到了接近 20Mb,增幅超过 200% !感谢!

@xqzr 另外 nginx.conf 中监听项的 so_keepalive=on 需要保留吗?

server {
   listen ... so_keepalive=on;
   ...
}

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

@xqzr 另外 nginx.conf 中监听项的 so_keepalive=on 需要保留吗?

server {
   listen ... so_keepalive=on;
   ...
}

需要 不然一堆“死连接”

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

另外 想了解下 你的 sendfile
grep sendfile /etc/nginx/nginx.conf

@ghost
Copy link
Author

ghost commented Mar 7, 2022

另外 想了解下 你的 sendfilegrep sendfile /etc/nginx/nginx.conf

sendfile on;

刚才又重新测试了几台不同地区不同线路的服务器。发现使用了 client_body_buffer_size 512k; 之后,客户端下行带宽能从原来的总带宽 15% 提升到 60% 左右;客户端上行带宽能从原来的总带宽 15% 提升到 30% 左右。

@ghost
Copy link
Author

ghost commented Mar 7, 2022

@xqzr 另外 nginx.conf 中监听项的 so_keepalive=on 需要保留吗?

server {
   listen ... so_keepalive=on;
   ...
}

需要 不然一堆“死连接”

因为没有使用端口使用的是 unix domain socket ,也不知道那种用法是对的 -_-''

server {
    listen unix:/dev/shm/h2c.sock http2 so_keepalive=on proxy_protocol;
    ...
}
server {
    listen unix:/dev/shm/h2c.sock http2 proxy_protocol so_keepalive=on;
    ...
}

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

刚才又重新测试了几台不同地区不同线路的服务器。发现使用了 client_body_buffer_size 512k; 之后,客户端下行带宽能从原来的总带宽 15% 提升到 60% 左右;客户端上行带宽能从原来的总带宽 15% 提升到 30% 左右。

thx 想请你帮忙测试一下 把 client_body_buffer_size 替换为 grpc_buffer_size 看看效果

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

server {
    listen unix:/dev/shm/h2c.sock http2 so_keepalive=on proxy_protocol;
    ...
}
server {
    listen unix:/dev/shm/h2c.sock http2 proxy_protocol so_keepalive=on;
    ...
}

看漏了...没有监听端口(TCP)的话 不需要 可以去掉

@ghost
Copy link
Author

ghost commented Mar 7, 2022

刚才又重新测试了几台不同地区不同线路的服务器。发现使用了 client_body_buffer_size 512k; 之后,客户端下行带宽能从原来的总带宽 15% 提升到 60% 左右;客户端上行带宽能从原来的总带宽 15% 提升到 30% 左右。

thx 想请你帮忙测试一下 把 client_body_buffer_size 替换为 grpc_buffer_size 看看效果

client_body_buffer_size 512k; 替换成了 grpc_buffer_size 512k; ,测了五、六次,平均算下来上下行带宽跟前面测出来的结果差不多:

刚才又重新测试了几台不同地区不同线路的服务器。发现使用了 client_body_buffer_size 512k; 之后,客户端下行带宽能从原来的总带宽 15% 提升到 60% 左右;客户端上行带宽能从原来的总带宽 15% 提升到 30% 左右。

@xqzr 上面是 Win64 的客户端测试结果;但如果是在软路由 Arm64 平台的客户端测试,下行少到只有总带宽的 10% 左右,上行带宽却翻倍了,能到 50~60% 。(失误了,忘记监听全端口了,Speedtest 测速使用的是非常规端口 O(∩_∩)O哈哈~ 实测结果与 Windows 客户端一致。)

@xqzr
Copy link
Contributor

xqzr commented Mar 7, 2022

client_body_buffer_size 512k; 替换成了 grpc_buffer_size 512k; ,测了五、六次,平均算下来上下行带宽跟前面测出来的结果差不多:

辛苦 如果都去掉呢?
我自测 加与不加都差不多 Linux amd64(可能我带宽小)

@ghost
Copy link
Author

ghost commented Mar 8, 2022

再多问一句,"multiMode": true 是客户端与服务端都需要设置,还是说服务端自适应(可以不用设置)?

仅 客户端

@xqzr 建议更新官方文档 GRPCObject 文档,为 multiMode 描述添加像 idle_timeout 样的描述文字,如“仅需在客户端配置”。

@xqzr
Copy link
Contributor

xqzr commented Mar 8, 2022

@xqzr 建议更新官方文档 GRPCObject 文档,为 multiMode 描述添加像 idle_timeout 样的描述文字,如“仅需在客户端配置”。

已提交 PR 但目前没人审核

@xqzr
Copy link
Contributor

xqzr commented Mar 8, 2022

client_body_buffer_size 512k; grpc_buffer_size 512k;
如果都 加上 效果如何?

@ghost
Copy link
Author

ghost commented Mar 8, 2022

client_body_buffer_size 512k; grpc_buffer_size 512k; 如果都 加上 效果如何?

nginx.conf 添加 client_body_buffer_size 512k; 使用相同测速节点测速三次;(CPU 未满载)

移动 200Mb 专线

  • 168 ms / 114.87 Mb / 46.91 Mb
  • 173 ms / 118.00 Mb / 60.24 Mb
  • 172 ms / 121.60 Mb / 58.99 Mb

电信 500Mb/30Mb 宽带

  • 137 ms / 145.53 Mb / 30.14 Mb
  • 135 ms / 146.81 Mb / 30.01 Mb
  • 138 ms / 139.05 Mb / 29.78 Mb

nginx.conf 添加 client_body_buffer_size 512k;grpc_buffer_size 512k; 使用相同测速节点测速三次。(CPU 未满载)

移动 200Mb 专线(延时变高了,看了下路由,没有直接进到省内的电信 CN2 ,绕路了。)

  • 225 ms / 91.94 Mb / 16.27 Mb
  • 226 ms / 92.85 Mb / 38.09 Mb
  • 226 ms / 95.92 Mb / 58.86 Mb

电信 500Mb/30Mb 宽带

  • 137 ms / 149.41 Mb / 29.47 Mb
  • 137 ms / 136.87 Mb / 30.14 Mb
  • 138 ms / 123.98 Mb / 30.09 Mb

@xqzr
Copy link
Contributor

xqzr commented Mar 8, 2022

nginx.conf 添加 client_body_buffer_size 512k; 使用相同测速节点测速三次;(CPU 未满载)

移动 200Mb 专线

  • 168 ms / 114.87 Mb / 46.91 Mb
  • 173 ms / 118.00 Mb / 60.24 Mb
  • 172 ms / 121.60 Mb / 58.99 Mb

电信 500Mb/30Mb 宽带

  • 137 ms / 145.53 Mb / 30.14 Mb
  • 135 ms / 146.81 Mb / 30.01 Mb
  • 138 ms / 139.05 Mb / 29.78 Mb

nginx.conf 添加 client_body_buffer_size 512k;grpc_buffer_size 512k; 使用相同测速节点测速三次。(CPU 未满载)

移动 200Mb 专线(延时变高了,看了下路由,没有直接进到省内的电信 CN2 ,绕路了。)

  • 225 ms / 91.94 Mb / 16.27 Mb
  • 226 ms / 92.85 Mb / 38.09 Mb
  • 226 ms / 95.92 Mb / 58.86 Mb

电信 500Mb/30Mb 宽带

  • 137 ms / 149.41 Mb / 29.47 Mb
  • 137 ms / 136.87 Mb / 30.14 Mb
  • 138 ms / 123.98 Mb / 30.09 Mb

感谢!看来 client_body_buffer_size 512k; 很重要 有必要添加

@ghost
Copy link
Author

ghost commented Mar 10, 2022

关于部分线路 gRPC 过 Nginx 后 降速问题 可能的原因。
可能是因为 Ngimx 不回复 大量的 h2 ping,而 线路差 需要一直调窗口大小,而调 窗口大小 需要 h2 ping。

可以尝试不经过 Nginx。

@xqzr 你好,想问下目前 Xray 支持设置 window size 吗?

我看软路由 SSR Plus+ 组件设置里有这一项,但是官方文档里没看到有相关的 cvar 介绍。如果支持的话, cvar 是什么?值设置多少合适?

@moranno
Copy link

moranno commented Jul 12, 2022

请问下@benhon-han
经过这一段时间的使用和调试,你现在grpc的速度是否有所提升?
在我的实际使用中,grpc在晚高峰的时候经常出现连不上的情况(连接断开,浏览器显示“该页无法显示”,多次刷新后可以打开)不知道是grpc断流还是被GFW阻断?

在丢包率在20%的网络环境下:trojan grpc和trojan tcp的测速对比。
多线程:
photo_2022-07-05_22-49-37

单线程:
photo_2022-07-05_22-42-40

另外grpc还有个最大的劣势,因为会保持长连接和多路复用,所以当有多台服务器做负载均衡,多线程的TCP应用不会连接到多台服务器做负载均衡。所以grpc可能天然不适合做负载均衡。不知道未来的QUIC在这方面会不会更有优势?

@chika0801
Copy link
Contributor

请问下@benhon-han 经过这一段时间的使用和调试,你现在grpc的速度是否有所提升? 在我的实际使用中,grpc在晚高峰的时候经常出现连不上的情况(连接断开,浏览器显示“该页无法显示”,多次刷新后可以打开)不知道是grpc断流还是被GFW阻断?

在丢包率在20%的网络环境下:trojan grpc和trojan tcp的测速对比。 多线程: photo_2022-07-05_22-49-37

单线程: photo_2022-07-05_22-42-40

另外grpc还有个最大的劣势,因为会保持长连接和多路复用,所以当有多台服务器做负载均衡,多线程的TCP应用不会连接到多台服务器做负载均衡。所以grpc可能天然不适合做负载均衡。不知道未来的QUIC在这方面会不会更有优势?

grpc要好回程线路(对你)的vps用

跑quic上隔壁tuic 或 hy 都行

@ghost
Copy link
Author

ghost commented Jul 12, 2022

我目前主力还是使用 gRPC 协议,因为握手响应超快,这个对我吸引比较大,我浏览网页较多,视频较少。

速度还是老样子,不过我 ISP 提供的带宽够多,服务器带宽也充足,所以用下来也足够了。

@moranno 另外实测下来,使用 gRPC 协议对线路质量要求非常高,稍微有些丢包或延时波动使用体验就会很差。

还有你说的劣势也是存在的,因为 gRPC 自带复用,就像 mux 的“传统技艺”一样。一个典型的场景:你开了多个视频,每个视频就看几秒钟然后关掉,这时后台流量其实还在跑,直到带宽耗尽……

@moranno
Copy link

moranno commented Jul 12, 2022

跑quic上隔壁tuic 或 hy 都行

谢谢,求个tuic项目地址?

@chika0801
Copy link
Contributor

跑quic上隔壁tuic 或 hy 都行

谢谢,求个tuic项目地址?

谷歌搜github tuic 就有

@moranno
Copy link

moranno commented Jul 12, 2022

我目前主力还是使用 gRPC 协议,因为握手响应超快,这个对我吸引比较大,我浏览网页较多,视频较少。

今天花了半天详细测试了tuichysteria,感觉quic才是战未来东西,不仅响应飞快(0-RTT):
下面测试均启用证书验证:

curl  -w "%{time_total}\n" --proxy localhost:7890 -s youtube.com
0.903764 <---grpc首次连接
curl  -w "%{time_total}\n" --proxy localhost:7890 -s youtube.com
0.448000 <---grpc再次连接(连接保持,应该没有tls握手)

curl  -w "%{time_total}\n" --proxy localhost:1080 -s youtube.com
0.221218 <---tuic首次连接
curl  -w "%{time_total}\n" --proxy localhost:1080 -s youtube.com
0.215625 <---tuic再次连接

而且相比tcp+tls在线路质量差(丢包20%+)的vps上有奇效,hysteria的测试基本上是单线程speedtest.net 50-100倍的提升(多线程50-100倍),也没有遇到QOS的问题。

希望benhon-han也来测试下。

对比tuichysteria
hy使用自己的拥塞控制(?)可以手动设置带宽上限来暴力发包,速度更快,但对VPS不太友好,CPU跑满,IDC可能认为你ddos。
tuic使用BBR等拥塞控制,更克制,更友好,测试下来也有5-10倍的单线程提升(多线程50倍)。期待你的测试感受。

@chika0801
Copy link
Contributor

你可以加xray群,本群已经从hy群再转向tuic群了。。。

@bash99
Copy link

bash99 commented Jul 13, 2022

你可以加xray群,本群已经从hy群再转向tuic群了。。。
tg上的xray群?私个群号?

tuic貌似没faketcp模式,碰到udp qos时有点难受,当然可以再套udp2raw之类的工具。

另外我比较喜欢的客户端Clash.Meta新加了hy的支持。

当然我现在还是用clash的urltest模式测多个grpc,靠测速及时切换来解决偶尔卡顿的问题

@bash99
Copy link

bash99 commented Jul 13, 2022

curl -w "%{time_total}\n" --proxy localhost:7890 -s youtube.com
0.448000 <---grpc再次连接(连接保持,应该没有tls握手)

这个有一点点随机性,可以多试一两次,应该也会收敛到0.22秒

@chika0801
Copy link
Contributor

chika0801 commented Jul 13, 2022

你可以加xray群,本群已经从hy群再转向tuic群了。。。
tg上的xray群?私个群号?

tuic貌似没faketcp模式,碰到udp qos时有点难受,当然可以再套udp2raw之类的工具。

另外我比较喜欢的客户端Clash.Meta新加了hy的支持。

当然我现在还是用clash的urltest模式测多个grpc,靠测速及时切换来解决偶尔卡顿的问题

建议你花钱(加钱)买1个好回程对你(有cn优化的)vps,不必天天测n个vps哪个好再选用哪个了

好回程(优化)的vps随便开tcp grpc quic都能跑

@bash99
Copy link

bash99 commented Jul 13, 2022

建议你花钱(加钱)买1个好回程对你(有cn优化的)vps,不必天天测n个vps哪个好再选用哪个了

只是用着玩,我有个BWG的37刀/年的cn2-gia线路。

@fefz
Copy link

fefz commented Jul 14, 2022

完整配置文件能分享下吗?在ARM上用unix socket不起作用。

@chika0801
Copy link
Contributor

完整配置文件能分享下吗?在ARM上用unix socket不起作用。

我的模板

https://github.com/chika0801/Xray-examples/tree/main/VLESS-gRPC-TLS

@fefz
Copy link

fefz commented Jul 14, 2022

感谢,vless能换成trojan吗?

@chika0801
Copy link
Contributor

感谢,vless能换成trojan吗?

可以

@fefz
Copy link

fefz commented Jul 14, 2022

感谢,vless能换成trojan吗?

可以

还是权限问题,报错。

2022/07/14 10:52:09 [Warning] core: Xray 1.5.4 started
2022/07/14 10:52:09 [Error] transport/internet/grpc: failed to listen on /dev/shm/grpc.socket,0666 > open /dev/shm/grpc.socket.lock: permission denied

@chika0801
Copy link
Contributor

感谢,vless能换成trojan吗?

可以

还是权限问题,报错。

2022/07/14 10:52:09 [Warning] core: Xray 1.5.4 started
2022/07/14 10:52:09 [Error] transport/internet/grpc: failed to listen on /dev/shm/grpc.socket,0666 > open /dev/shm/grpc.socket.lock: permission denied

你把客户和服务器xray版本都更新在158试试

@fefz
Copy link

fefz commented Jul 14, 2022

服务端升级到1.5.8了,客户端使用shadowrocket, CFW,v2rayN 1.5.8 core都试了,还是连不上

@chika0801
Copy link
Contributor

服务端升级到1.5.8了,客户端使用shadowrocket, CFW,v2rayN 1.5.8 core都试了,还是连不上

vps端你更改过配置 确定重启xray成功了的吗?reboot肯定能保证配置重新加载了

其它原因想不出来,要不你加xraytg群问网友 剩下只能靠自己

@WROIATE
Copy link

WROIATE commented Jul 25, 2022

我是发现之前在联通的宽带下grpc可以跑满200m,但是换成电信以后被限死在10~20m左右(包括websocket等长连接协议),但其它协议是正常的,不知道什么原因

@chika0801
Copy link
Contributor

我是发现之前在联通的宽带下grpc可以跑满200m,但是换成电信以后被限死在10~20m左右(包括websocket等长连接协议),但其它协议是正常的,不知道什么原因

建议出门,用隔壁hy 233
https://github.com/HyNetwork/hysteria
别花时间研究grpc了

@WROIATE
Copy link

WROIATE commented Jul 25, 2022

我是发现之前在联通的宽带下grpc可以跑满200m,但是换成电信以后被限死在10~20m左右(包括websocket等长连接协议),但其它协议是正常的,不知道什么原因

建议出门,用隔壁hy 233 https://github.com/HyNetwork/hysteria 别花时间研究grpc了

这个我试用了,但是在路由器的passwall应用上会出现客户端重启的问题,这个我之后回去排查下;高峰期感觉抖动(丢包)比传统的tcp协议要高(我玩master duel会出现掉线),带宽貌似能跑到100m。
还有就是这个协议貌似没有回落功能,我还不太清楚在如今的伪装站点潮流下是否属于容易被识别的

@chika0801
Copy link
Contributor

chika0801 commented Jul 25, 2022

hy设计时就没回落功能。

你在路由跑passwall不稳这情况太复杂不好说是什么原因。我在ssrp测了hy,至少ssrp插件没什么bug。

hy要在客户端设置好上,下的最大速度。

然后再建议个先在win上搞客户端,配这些体验下,最后搞到软路由翻墙上用(比如hy吃cpu,软路由上不是x86的u的话

@hedsbj
Copy link

hedsbj commented Aug 28, 2022

用caddy 取代nginx速度能完全跑起来

@ChainZeaxion
Copy link

location 默认是 模糊匹配。 location = 是全字匹配。

求助一下
前置nginx,后置vmess grpc
开了multi之后,客户端用gun能正常
用multi,连不通,看nginx日志,是向后正常代理返回200ok

171.219.. - - [25/Oct/2022:23:28:04 +0800] "POST /alipay-cdn/TunMulti HTTP/2.0" 200 0 "-" "grpc-go/1.47.0"
171.219.. - - [25/Oct/2022:23:28:04 +0800] "POST /alipay-cdn/TunMulti HTTP/2.0" 200 0 "-" "grpc-go/1.47.0"
171.219.. - - [25/Oct/2022:23:28:04 +0800] "POST /alipay-cdn/TunMulti HTTP/2.0" 200 0 "-" "grpc-go/1.47.0"
客户端multi,安卓,linux,windows都一样,不通

171.218.. - - [25/Oct/2022:23:28:32 +0800] "POST /alipay-cdn/Tun HTTP/2.0" 200 4311 "-" "grpc-go/1.36.0"
171.218.. - - [25/Oct/2022:23:28:41 +0800] "POST /alipay-cdn/Tun HTTP/2.0" 200 5519 "-" "grpc-go/1.36.0"
客户端ios,安卓,linux,windows都一样,可通

我这是不是nginx还有啥参数不对?

location /alipay-cdn {
if ($content_type !~ "application/grpc") {
return 404;
}
grpc_set_header Host $host;
grpc_set_header X-Real-IP $remote_addr;
grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

grpc_set_header X-Real-IP $proxy_add_x_forwarded_for; #cdn $proxy_add_x_forwarded_for;#X-Real-IP $remote_addr;

	grpc_pass unix:/dev/shm/grpc.socket;
}

@Xingeqwd
Copy link

location 默认是 模糊匹配。 location = 是全字匹配。

求助一下 前置nginx,后置vmess grpc 开了multi之后,客户端用gun能正常 用multi,连不通,看nginx日志,是向后正常代理返回200ok

171.219.. - - [25/Oct/2022:23:28:04 +0800] "POST /alipay-cdn/TunMulti HTTP/2.0" 200 0 "-" "grpc-go/1.47.0" 171.219.. - - [25/Oct/2022:23:28:04 +0800] "POST /alipay-cdn/TunMulti HTTP/2.0" 200 0 "-" "grpc-go/1.47.0" 171.219.. - - [25/Oct/2022:23:28:04 +0800] "POST /alipay-cdn/TunMulti HTTP/2.0" 200 0 "-" "grpc-go/1.47.0" 客户端multi,安卓,linux,windows都一样,不通

171.218.. - - [25/Oct/2022:23:28:32 +0800] "POST /alipay-cdn/Tun HTTP/2.0" 200 4311 "-" "grpc-go/1.36.0" 171.218.. - - [25/Oct/2022:23:28:41 +0800] "POST /alipay-cdn/Tun HTTP/2.0" 200 5519 "-" "grpc-go/1.36.0" 客户端ios,安卓,linux,windows都一样,可通

我这是不是nginx还有啥参数不对?

location /alipay-cdn { if ($content_type !~ "application/grpc") { return 404; } grpc_set_header Host $host; grpc_set_header X-Real-IP $remote_addr; grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

grpc_set_header X-Real-IP $proxy_add_x_forwarded_for; #cdn $proxy_add_x_forwarded_for;#X-Real-IP $remote_addr;

	grpc_pass unix:/dev/shm/grpc.socket;
}

老兄,偶然看到你的发言,我来帮帮忙看看,你格式太乱了点,大概看了看

你这个是不是有点矛盾。。。

开了multi之后,客户端用gun能正常
用multi,连不通

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests