rejected proxy/vless/encoding: failed to read request version

[MrsZ]

2023/01/09 13:03:49 119.160.69.241:21930 rejected proxy/vless/encoding: failed to read request version > read tcp 2.26.14.170:28820->119.160.69.241:21930: read: connection timed out

服务器日志有大量的这种错误，麻烦咨询一下 是什么类型的问题呢 谢谢

[RPRX]

连接超时，比如外部 TLS 握手超时，或握手成功但没发任何数据，服务端谁都能访问，有这样的日志很正常，not an issue

当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒

[RPRX]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显

中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥

[yuhan6665]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显

~中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥~

是不是可以理解：

• 回落仍然是必要的
• 如果可以Nginx前置的情况（非xtls）前置更好一点

[RPRX]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显 ~中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥~

是不是可以理解：

* 回落仍然是必要的

* 如果可以Nginx前置的情况（非xtls）前置更好一点

回落当然是必要的，尤其是现在我们大规模用 uTLS 模仿浏览器指纹，GFW 一个探测，没网页的话岂不是一眼假？

服务端指纹特征是一个值得解决的问题。

[yuhan6665]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显 ~中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥~

是不是可以理解：

* 回落仍然是必要的

* 如果可以Nginx前置的情况（非xtls）前置更好一点

回落当然是必要的，尤其是现在我们大规模用 uTLS 模仿浏览器指纹，GFW 一个探测，没网页的话岂不是一眼假？

服务端指纹特征是一个值得解决的问题。

曾经考虑过 像 naive 一样 fork 一个 forward proxy TLS 处理完把 conn 传递给 xray。。感觉有点麻烦

[RPRX]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显 ~中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥~

是不是可以理解：

* 回落仍然是必要的

* 如果可以Nginx前置的情况（非xtls）前置更好一点

回落当然是必要的，尤其是现在我们大规模用 uTLS 模仿浏览器指纹，GFW 一个探测，没网页的话岂不是一眼假？ 服务端指纹特征是一个值得解决的问题。

曾经考虑过 像 naive 一样 fork 一个 forward proxy TLS 处理完把 conn 传递给 xray。。感觉有点麻烦

（我还是说得更明白一点：Reality 协议可以解决该问题）

[cross-hello]

Don't you want to prepare some surprises for the next time big-scale blocking? 

Delaying publish to the time? ︶

Jan 14, 2023 00:26:22 RPRX @.***>:

…

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显 中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥

是不是可以理解：

** 回落仍然是必要的

• 如果可以Nginx前置的情况（非xtls）前置更好一点

• 回落当然是必要的，尤其是现在我们大规模用 uTLS 模仿浏览器指纹，GFW 一个探测，没网页的话岂不是一眼假？ 服务端指纹特征是一个值得解决的问题。

曾经考虑过 像 naive 一样 fork 一个 forward proxy TLS 处理完把 conn 传递给 xray。。感觉有点麻烦

（我还是说得更明白一点：Reality 协议可以解决该问题）

— Reply to this email directly, view it on GitHub[https://github.com/XTLS/Xray-core/issues/1511#issuecomment-1382084979], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYDF7WNKKWMRD6WASI3WSF623ANCNFSM6AAAAAATVNKB7E]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYGBTCVGKUMMMMM5JF3WSF623A5CNFSM6AAAAAATVNKB7GWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSSMDYXG.gif]

[yuhan6665]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显 ~中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥~

是不是可以理解：

* 回落仍然是必要的

* 如果可以Nginx前置的情况（非xtls）前置更好一点

回落当然是必要的，尤其是现在我们大规模用 uTLS 模仿浏览器指纹，GFW 一个探测，没网页的话岂不是一眼假？ 服务端指纹特征是一个值得解决的问题。

曾经考虑过 像 naive 一样 fork 一个 forward proxy TLS 处理完把 conn 传递给 xray。。感觉有点麻烦

（我还是说得更明白一点：Reality 协议可以解决该问题）

那我懂了 是传说级超越改进 shadowtls 的协议

[Fangliding]

@RPRX 快点端上来罢

[RPRX]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显 ~中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥~

是不是可以理解：

* 回落仍然是必要的

* 如果可以Nginx前置的情况（非xtls）前置更好一点

回落当然是必要的，尤其是现在我们大规模用 uTLS 模仿浏览器指纹，GFW 一个探测，没网页的话岂不是一眼假？ 服务端指纹特征是一个值得解决的问题。

曾经考虑过 像 naive 一样 fork 一个 forward proxy TLS 处理完把 conn 传递给 xray。。感觉有点麻烦

（我还是说得更明白一点：Reality 协议可以解决该问题）

那我懂了 是~传说级超越~改进 shadowtls 的协议

小了，格局小了。

Reality：超越 TLS 的现实协议。

（不好意思刚刚没引用到，重发）

[npwc]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显 ~中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥~

是不是可以理解：

* 回落仍然是必要的

* 如果可以Nginx前置的情况（非xtls）前置更好一点

回落当然是必要的，尤其是现在我们大规模用 uTLS 模仿浏览器指纹，GFW 一个探测，没网页的话岂不是一眼假？ 服务端指纹特征是一个值得解决的问题。

曾经考虑过 像 naive 一样 fork 一个 forward proxy TLS 处理完把 conn 传递给 xray。。感觉有点麻烦

也许可以考虑像imgk/caddy-trojan这个项目那样在服务端利用forwardproxy，同时兼容trojan和naive，再加一个xray。

[RPRX]

~当然也有可能是被疯狂主动探测，记录握手超时时间，看像不像 Xray 的默认 60 秒~

对于这一点，我建议大家修改一下 policy 的 handshake 和 connIdle 等，不要用默认值，不然特征太明显 ~中间人多收集些数据，分析出握手 60 秒超时 + 连接 300 秒超时，这不是 *ray 还能是啥~

是不是可以理解：

* 回落仍然是必要的

* 如果可以Nginx前置的情况（非xtls）前置更好一点

回落当然是必要的，尤其是现在我们大规模用 uTLS 模仿浏览器指纹，GFW 一个探测，没网页的话岂不是一眼假？ 服务端指纹特征是一个值得解决的问题。

曾经考虑过 像 naive 一样 fork 一个 forward proxy TLS 处理完把 conn 传递给 xray。。感觉有点麻烦

也许可以考虑像imgk/caddy-trojan这个项目那样在服务端利用forwardproxy，同时兼容trojan和naive，再加一个xray。

其实 REALITY 已经解决了 XTLS 前置 Xray 带来的服务端指纹问题，而且 TLSv1.3 行为模式单一，后续处理想做到完全一样也很简单

Nginx、OpenSSL、BoringSSL 的代码我都看了，也经常改 Nginx 的代码并手动编译，所以若要选的话，我会选 Nginx 而不是 Caddy