https://github.com/yosebyte/nodepass

首先“预连接”这个技术早几年就讨论过了，懒得找链接，我还看过有个项目给 Trojan 搞“预连接”，不过没有 padding 就是强特征

几年前 REALITY 仓库写下的“XTLS 的下一个主要目标是 0-RTT”对 Vision 而言就是“预连接”，这不更早，不然它又没有复用该咋实现

只是以前的 VLESS outbound 有 vnext 多目标、users 多用户，写起来有点麻烦，现在只有一个 end point，一个小时就糊完了

再往前推一些就是我在“消失”前就预告的 REALITY，提到了吊打 XTLS、可以用别人的域名、不仅是真实的 TLS 还是 0-RTT（显然指的不是“多路复用”），我本来是想把这些东西全糊一起的，最后还是搞成了模块化设计、自由组合

说这些没有别的意思，只是防止有人找角度恶评说抄谁谁谁，并且说实话“预连接”这么简单的东西是个开发者都能自己想出来

至于为什么以前没普及，就是我说的原因，前提是你得有自由 padding 否则强特征，但是用得好的话它还能起到迷惑 GFW 的作用

Is it possible to use this with xhttp? without xhttp padding and separated up-down streams my node get blocked after few days
And please have a look at #5195

试了一下就炸掉
panic: runtime error: index out of range [-1]

goroutine 30 [running]:
github.com/xtls/xray-core/app/proxyman/outbound.(*Handler).Dial(0x4000324750, {0x13c4c88, 0x1ed6d60}, {{0x13c52f8, 0x400032c050}, 0x1144, 0x2})
github.com/xtls/xray-core/app/proxyman/outbound/handler.go:320 +0x844
github.com/xtls/xray-core/proxy/vless/outbound.(*Handler).Process.func1()
github.com/xtls/xray-core/proxy/vless/outbound/outbound.go:151 +0x108
created by github.com/xtls/xray-core/proxy/vless/outbound.(*Handler).Process in goroutine 29
github.com/xtls/xray-core/proxy/vless/outbound/outbound.go:142 +0x308

@Smallthing 上一次 force-push 前是不会炸的，但是第一个连接关闭后它的 ctx 被 cancel 会导致后面的 dial 不出去

所以换成了 background，我研究下需要 clone ctx 里的哪些值

看起来似乎把这处 panic 改掉，然后 VLESS outbound 加行代码赋值一下 ob.Conn 就行了，只是底层传输日志中 ctx id 会不一样

确实可行，e8aecbc 已修，经测试可以正常使用，你们再测测吧

@gfw-killer 这个 pre-connect 是给 RAW REALITY/Encryption 用的，XHTTP 自带复用，体感延迟本身就是 0-RTT，但可以用 Seed

@Fangliding 在群里提到了 senderSettings

简单看了下貌似它用到了 ctx 中的东西，所以这个 pre-connect 目前只适用于非 dialerProxy 的情况

翻出来些先前讨论

预连接：https://t.me/projectXtls/143 、#3560 (comment)

Seed：#1295 (comment) 、https://t.me/projectXtls/145

至于 Switch，明年上吧，还有 Mux/Reverse 增强、PLUX 等，说实话 pre-connect 出了后再加个游戏佬喜欢的 PLUX 就差不多了

现在感觉 pre-connect 潜力很大、会成为标配，如果想要原生 UDP 打游戏，那用 PLUX #3560 (comment) 可以替代，齐活了

这东西的预连接的超时怎么设置，大规模使用cdn图片后有时候会卡好一会，服务端看经常能产生60多个预连接，感觉复用逻辑是不是有点粗暴了

@Smallthing 超时是 TODO，还有你 testpre 设的 5 就最多有五个预连接，不会有六十多个

@Smallthing 连接数不等于预连接数啊，你应用层的连接没断开，代理层是 1:1 的，几十个不是很正常吗

其中有十个是预连接，你填的 5 就表明随时有 5 个预连接备用，如果被使用了就会自动开新的预连接，自动补至 5 个

我稍微重写了一下这个池逻辑 1e50e6e

@Fangliding 直接用 channel 的确更方便，不过得补上 sleep，不然可能会疯狂循环，还有直接 go func 就行

我把close的逻辑一起做了所以那里会略长 才提前拉出来的

@Fangliding 改成 channel 倒是方便了多次 go，要不改成 make channel 1 然后起多个 go 吧（实现了 concurrency 的 TODO），不然哪次阻塞了就全堵了，还有 timeout 的 TODO 你也加一下（它可能也需要 customize & randomize？）

然后 TODO 就只剩下了 sleep 的 customize & randomize，还有 vision paddings，至于 ctx mitm 我想了下似乎不需要

大概以下四个 customize & randomize：

• testpre
• sleep
• timeout
• vision paddings

先 sleep 再 dial，不然一下子 dial 出去 n 个，容易失败

Close 可以实现，inactive 我想了下不用管，没人用这个出站的话那些 conn 会自动断开，只是不太利于半小时一次的连接观测

err我想过了 遇到就让worker死掉 用用户的下一次请求来唤醒 熵更高 还不会出现断网静置反复尝试的问题 就是逻辑会比较复杂
起几个goroutine我想过 但是怕笨比填太好让它炸了
timeout不需要 dialer自带

自定义 timeout 什么的主要是减少特征吧，不然现在这功能直接就能 release 了

for testpre 里面 go 就行了

为啥要自定义timeout 这和普通的连接是一个超时机制啊 下面的transport基本都设置为 Chrome行为了

忘了下面的 transport 还有超时，那没事了

改成 for testpre，加一下 sleep 吧

打住，Close() 的问题已经解决了就别吵了，这 Close() 有没有人调用都不知道
好的

@Fangliding 不过我承认一点， 后面你改的那一版 拿走一个conn 就通知新建一个conn 是好的，这一点我没想到

哪里需要额外通知，channel 没压进去不就是阻塞了吗，压进去了不就可以继续新建 conn 了吗，你们越搞越复杂

哪里需要额外通知，channel 没压进去不就是阻塞了吗，压进去了不就可以继续新建 conn 了吗，你们越搞越复杂

他那个写法给了我一个启发，不是像现在这样 就等预连接，开始的时候也不用预热，而是用select 看能不能拿到预连接。没拿到预连接就用正常的连接，同时通知建立一条新的预连接，这个建立的预连接里面也不是for {} ,而是for range n{}, 这样可以避免连接失败还一直dial，同时也能根据网络流量动态开建立预连接的func

我提个pr 看看

#5361

Looks good to me！（作为最简实现）
长远来讲 这样的功能应该是广泛有用的 应该考虑如何加给其他协议或者 transport
虽然处理不当可能会增加一点特征 但是作为可选项 而且相比于之前爱好者群友们喜欢折腾的比如 tcp fast open 不管是可维护性 还是安全性都要更优

其实我给 yuhan 发消息让他看一下 PR 的意思是看一下 #5270 (comment) ，但他似乎没看到

934beb2 给 VLESS 出入站加了 testseed，用户可以自行修改 XTLS Vision 的 900 500 900 256 这几个最关键的 padding 相关参数

testpre 和 testseed 都是暂时的配置项，还不完善，功能也有限，这个月内会出正式版的 Seed 并加到分享链接中

cadcb47 小细节，ctx = 改为了 ctx :=

我捏的时候还专门写了个别的名 生怕不小心给外头盖了

话说测试下现在的代码能不能用，我懒得测试了，先去发版了

能用

vision 和xhttp试过

vless自己加密+xhttp("maxConcurrency": "16-32")+reality
我看了下说明是写的 但是只适合 Vision 这类有自由 padding 的协议 这套组合用不了vision，我就不测试加了。

vless自己加密+vision+reality

服务端入站也在settings-clients 里面加了"Testseed": [123,421,512,66]，与客户端出站的 "Testseed": [] 不同的值。

都是正常的。

c123f16 取出来发现是两分钟之前的就直接扔；顺便把等待 200 毫秒改到了 for 的最后，因为我想了一下同时 dial 几个也很正常

Golang channel 应该是先准备好数据再伺机压进去吧，那这个写法就没问题；半小时一次的连接观测不会失败了但吃不到减延迟

vision 和xhttp试过

大侠，预链接的配置是怎么样的？给个样例学习学习。谢谢！找了好几个链接，没有看到详细该如何配置。

vision 和xhttp试过

大侠，预链接的配置是怎么样的？给个样例学习学习。谢谢！找了好几个链接，没有看到详细该如何配置。

同求，目前只会一键脚本安装，在其基础上修改配置文件

@haomuch （或许可以查看此教程呀）