@cnfzv 如果将 TCP 视作为流，而不是报文。在客户端对服务端的响应预测无误的情况下，服务端仍不能正确处理流上数据，我觉得这是服务端的实现问题。

好东西，感谢作者

社会工程学：直接问装维小哥

@cnfzv udp 走 udp 传输的话，客户端要求有访问到服务器端任意 udp 端口的能力。

@cnfzv 如果 socks5 服务端不支持 udp associate 命令，只能支持 tcp/ip 。基于 udp 的 dns 也不能支持。换一些 socks5 服务端即可。

@specture hev-socks5-tunnel 只做 tun2socks 业务，如果有部分流量本地直连的需求，那么分流器要运行在本地侧。分流器是 socks5 服务器，通过 socks5 协议与 socks5-tunnel 交互。关于 fakedns 流程大概是这样：

1. 应用程序请求解析域名的 ip 地址，相应的 dns 请求发送到 tun 。
2. socks5-tunnel 收到 tun 上的 udp 协议的 dns 请求后，通过 socks5 udp associate 方式发送给分流器。
3. 分流器通过协议识别（比如目标端口或报文内容等）发现是 dns 请求，重定向请求至内部的 fakedns 模块，生成 fake ip 的 dns 响应，发回 socks5-tunnel 。
4. 应用程序收到 dns 响应后，开始发起对 fake ip 的访问。相应的 tcp 或 udp 报文再次被分流器捕获，分流器通过报文中目标地址的 fake ip 查找分流规则， 建立与远程服务器的连接。

@specture #21 在 Socks5 服务端做分流、规则策略等。

socks5 协议支持 udp 代理本不存在障碍，问题在于实现。

难道不是 xtcp 的 fallback 机制退回到 stcp(服务器中转)模式嘛

我这 7950x+32x4 ，跑不跑的稳和 BIOS 版本相关： https://hev.cc/posts/2023/128gb-ram-on-amd-ryzen-7950x/

@BitGeek #17 感谢，看到有一种说法是内存控制器在一个通道上只能配置一份参数，因此同一通道上的两条内存要尽可能相同。如果是这样的话，就是 12 一组，34 一组。

到底哪种对呢？

@catalysia #23 了解这个事情，现在用的 bios 也是修正了这个问题的。

@catalysia #19 我这 4 条对比过 3600 和 5200 的内存带宽，memtest86 里 3600 是 16GB/s ，5200 是 21.3GB/s 。差距还是挺大的，约 30%多呢。

@catalysia #15 我这使用旧点的 BIOS ，4 条双面内存可以稳定跑 XMP 5200 的： https://hev.cc/posts/2023/128gb-ram-on-amd-ryzen-7950x/

只是说更新 BIOS 后不行了，所以我这的结论和 BIOS 有关，只是具体是什么原因不清楚

@kruskal #14 我这 4 条双面 5200MHz 的默认可点亮，频率 3600MHz 。至于能不能开 XMP 稳定到 5200 ，目前看与 BIOS 相关度很大，主板是 Gigabyte B650 Gaming X 1.0 ，使用 F8 版本(AMD AGESA 1.0.0.6)则能开 XMP 到 5200 ，且 memtest86 通过。如果使用 F9 版本(AMD AGESA 1.0.0.7c)则内存训练失败。

@heiher #5 呵呵，我这是要卡在 1.0.0.6 这版 BIOS 了，升级到 AMD AGESA 1.0.0.7c 稳定版，32GBx4 的 XMP 5200 就是训练不成功。感觉这是 AMD 为了加速开机速度舍弃了训练质量。这对我这种不要求开机速度的重大利空！！！

@monzuguan #7 @shiji #8 @YaakovZiv #11 感谢，技嘉主板的说明书没写的那么细，只说 2 条优先用 2 和 4 ，4 槽全插满只能 3600 。感觉我这误打误撞反而做对了的样子。

@billlee #7 没，回退在用 1.0.0.6 的 bios ，之前 1.0.0.7c 的 bios 是个 beta 版本。今天刚看又更新了，1.0.0.7c 变成稳定版了，改天有空再升级测测看。

我这使用 AMD AGESA 1.0.0.6 的 BIOS ，启动时内存初始化时间就会比较长，尤其是第一次，memset86 稳定通过。BIOS 升级到 AMD AGESA 1.0.0.7c 后，启动速度明显加快。但是，即使硬件和内存频率不做任何改变的情况下，32GBx4 的内存也会跑不过 memtest86 。