RPRX
@IMIEEET 你时间多的话，不如你提出一个针对当前问题的 **有效解决方案**？注意是有效，而不是 YouTuber 还能继续教 http://ip *If you have time, why not propose an **effective solution** to the current problem? Note that it must be effective, not just something where...
网上流行的搭建私人代理的面板大都基于 Xray-core，其中 3X-UI 是占市场份额最多的，当我促使那些面板进行改变时，我曾经以为 3X-UI 的主要开发者 @MHSanaei @alireza0 会重视并致力于彻底解决这个问题，但他们并不想，反倒是其它面板禁止了 http://ip 注：以上仅为事实陈述，不包含任何引申猜想 *Most of the popular panel builders for private proxies on the Internet are based on Xray-core, and 3X-UI is...
@fodhelper allowInsecure 和 pin 证书这两个功能都是源自 v2ray-core，且前者比后者早了大概五年 在 Xray-core 制定的分享链接标准中 https://github.com/XTLS/Xray-core/discussions/716 ，**allowInsecure 不允许被分享，旨在阻止这样的节点被方便地传播** 不过我不确定这样做是否足够，我确实考虑过彻底移除 allowInsecure 选项，但仍有一些特殊用途确实需要这个选项 **这与面板不设置任何门槛即可默认的、且已经被大量滥用的、靠纯记录流量即可获取数据的 http://ip 问题的严重程度不可一语** 在大量的 VLESS REALITY/TLS 教程之外，你当然可以找到 YouTuber 教 VLESS non-TLS 的例子，但是面板问题的情形是与之完全相反 *@fodhelper allowInsecure and...
五年前 XTLS 推出后我也想过要不要只 hide sni，没实践是因为要另开一条连接去传递真正的 SNI，且 server response 形态各异容易露馅，TLSv1.2 更是不适用，不过现在 ECH 开始推广了，填入 ECH 的 SNI 说不定有希望，优点是真实客户端指纹、无 TLS in TLS 握手 说起来最近 uTLS 疏于维护，我想了另一个东西，就是 REALITY 不是能 clone 服务端 TLS 指纹吗，我想让它也 clone...
现在是五年后了，TLSv1.3 比当时更加普及，可能直接禁掉 TLSv1.2 也不会有太大影响 即使是 TLSv1.3，SNI 确定时服务器发的 Server Hello 和后续握手消息的长度基本不变，所以用不同的 SNI、表现为 SNI 分流更好 用 ECH 的 SNI 不知道是否能解决问题，因为即使是 ECH，处理 TLS 握手的基本上还是同一个服务端 ~~更深入的问题就是如果你这个 SNI 被 GFW 改了怎么办？正常的 TLS 会被服务端弹 alert，所以“另一条连接”还需要发 hash...
> 或许把内层 TLS hello 作为 ECH 数据藏进外层 TLS hello 的 extension 是个更优解 补充一下，这样的话要给浏览器本身关掉 ECH extension 不然数据量异常大，而更多 APP 是关不掉的，所以可能不能广泛适用 还有服务端会表现为每次都先发一些数据，可能会有点怪，~~还是 Switch 或完全多路复用吧~~ --- > *Perhaps hiding the inner TLS hello as...
生成 .pb.go 先用和 main 一致的吧 纯 QUIC 的话我感觉 TLS+ALPN H3 这种配置方式更合适 这个怎么识别它要传输的是 UDP，以及 H3 好像也能 datagram，试试直接加进 XHTTP？
这个与 VLESS/XUDP 层面配合的话可以实现传输 unreliable UDP，或者 TUN TCP，IP 包 ICMP 之类的，也需要给 VLESS 加料 之前频道对线我有提过想给 XHTTP H3 加个 datagram，这是 QUIC/Hy/TUIC 有的功能，我看了下 H3 也有，应该能加 能藏在 Nginx 后面、直连能用就行，不追求过 CDN，然后再给 Nginx QUIC 改个 gentle 发包，表现上应该不输...
就是说我觉得不是 QUIC datagram 有没有 mux 的问题，而是不加个伪装站的话一个主动探测就没了，所以应该搞 H3 datagram 之前把 QUIC、HTTP 传输层删了也是同理，前者没伪装站，后者没 header padding https://github.com/XTLS/Xray-core/issues/3272#issuecomment-2585736479 ，都太假了，没必要
我觉得既然现在这些 QUIC 代理都是服务端 quic-go 特征，我们搞个差异化的能藏到 Nginx 后面更好，提供它们没有的价值 没 padding 的问题，只要有设计当然就不是问题，但是强制 padding 就成新协议了，没必要再继承 HTTP 传输层这种名字 QUIC 这块的话弄 fallbacks 或内置 Web，这是 REALITY 出现以前的思路，日后弄 REALITY QUIC 就覆盖了直接 QUIC 的需求