留几块老硬盘，偶尔通电可以看到过去的自己在忙碌什么。

因为酷Q ，我第一次接触到了Docker和基于Openbox窗口管理器和Wine 的Linux下Windows服务软件运行方案。

我是中国境内较早一批接触并实用AI chat模型的非计科高中生。​

那时候腾讯还在ai.qq.com持续测试传统NLP 算法的chat模型，即便效果远不能与现在的LLM相比拟，这些现在可以称为古董的早期产品还是给当时的我还有其他朋友带来了极大的震撼。

​那年，眺望世界已经不能依靠原版shadowsocks实现，新的替代者是Trojan

那年，Discuz是境内主流论坛服务软件。

​那年，Python有了一个国产IDE NovalIDE。

​那年，SSH 还是XShell Plus的天下。

​那年，PanDownload 和无私分享的cookies拯救无数被百度云盘困住的用户。

那年，PCL替代不掉难忘的旋律

那年，联机侠跨越时空提前挤占了网易的用户空间

​那年，我第一次玩孤岛危机2 大型开放世界FPS游戏。

那年，第一次体验COD 4颠覆性游戏制作水平

​那年，激活Windows只需要启动AAct 。

​那年，酷Q与论坛还在，开发可用易语言。

​互联网有记忆，我们也有，缺少的记忆欢迎补全。

光猫路由一体机拨号是一个极其糟糕的设计，运营商既不愿意普及高性能硬件NAT的设备又不愿意用户自己使用路由器拨号。
这个问题淘宝花30块钱就可以解决，专业的事情交给专业的人做。
在花小钱之后我的宽带体验明显有了质的提升，首先是ping 延迟明显比之前光猫拨号再接路由器低了5~8ms
此外，之前光猫拨号会存在长时间使用后延迟异常超高抖动丢包率的问题也迎刃而解。
顺便也算绕开了光猫里的老大哥的眼睛（我给你光模块供电就算了，我还得自付电费审查自己是吧，我有病吗？）

驱动怎么掉的

我的是RTX5060 laptop，不管是第三方软件还是Nvidia 自己的app都无法识别到。
我猜是Windows的傻逼更新自动替换驱动把我驱动甘飞了，当然最近一次使用Windows也就是下了Todesk花30让人帮忙处理光猫的时候，最近一个星期我都在用Fedora。所以要么是Windows作妖，要么是Todesk在瞎搞。
个人倾向于前者。

解决方案

下载DDU：Download Display Driver Uninstaller (DDU) Official Latest Version
按下Shift 再点击重启

重启后选择进入安全模式（藏得有点深，可别点成清除数据恢复Windows了）
在安全模式打开DDU 第一次启动会自动启动选项弹窗：

注意大弹窗下的高级设置：
勾选：

安全模式下是无法安装N卡驱动的，重启后自动退出安全模式。
此时直接安装驱动仍然会识别不到驱动，需要通过Lenovo Legion Toolkit 或者你在OEM提供的其他官方工具（亦或者主板勾选）切换到独显直连模式才会使得Windows正常识别到显卡。
此时设备管理器会显示一个微软基本显示设备实际上就是你那个没装驱动的显卡，正常安装驱动即可。

在关闭Frp的tcp mux 后上传才正常持续，之前是小文件可以秒传卡100%，大就传一下等待一会儿就报错Network Error（仅使用Frp进行端口转发的情况下）如果再加上Nginx进行反向代理没有写明超时时间，默认60s就更完蛋了，给你报405/502/504等一串错误。
HK 大陆3网直连 200Mbps的VPS做转发，一个30MB的文件1MB分片已经传了十几分钟了，真的逆天啊我很难想想这性能瓶颈到哪里了，哪怕作为下载方的家宽服务器现在也有100Mbps下行，我本地直接5G流量居然还是这么龟速。 纯纯逆天。
折腾这个玩意真的让我力竭了，当然力竭的倒霉蛋也不只我一个，互联网上随手就能搜到类似的问题，而且最终说是解决的实际和没解决也区别不大，依旧是慢如蜗牛。

先来谈谈Frp TCP多路复用的降速问题

看个帖子：tcpmux 会大幅降低链路速度#2987
看完你应该大致明白发生了啥，总之开发者们选择了稳定性，但是这在我的应用场景就很糟糕。
所以我最终选择了关闭TCP MUX。

Nginx 反代对Cloudreve的影响

首先，我刚才提过Nginx对前后端的默认的连接超时都是60s一超时就给前端返回504，所以你要么60s内传完，要么保障断开连接后自动重连。
当然，我们还有个更具备实操价值的办法😉：

  location / {
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host; 
        proxy_redirect off;
        proxy_pass http://127.0.0.1:5212;  
        proxy_request_buffering off; # 禁用反向代理缓存
        proxy_read_timeout 3600s;   # 等待后端响应超时
        proxy_send_timeout 3600s;   # 发送请求体给后端
        client_body_timeout 3600s;  # 接收客户端请求体
        send_timeout 3600s;         # 发送响应给客户端

        client_max_body_size 0;     # 0 表示不限制请求体大小
    }

分片大小

在带宽足够的情况下，为了充分吃满带宽分片大小应该尽可能的大以提高[所求数据传输时间/协议开销时间]的值，拆分成小块发送意味着花费更多的时间在协议开销上。具体大小应该根据你自己的各级服务器带宽决定，如果带宽本身就很低或者波动明显，就适当调小维持稳定上传状态。
对于我的200Mbps上行的Frps和30上/100Mbps下的Frpc 我选择的分片大小是16MB。

Frps与Frpc 之间的协议效率

在理想的情况下，QUIC一定是最好的选择，如果网络波动明显只能退选KCP。但是考虑到实践中某些运营商对UDP流量极端的QoS策略，我只能选择TCP和基于TCP的协议。
在某些特殊环境下，开启流量加密是你不得不做的选择，但是如无必要加密和压缩两个都没有必要开，特别是设备cpu性能明显羸弱的情况下，开启流量压缩没有任何意义。

最后，看看更接近操作系统底层的地方

Linux之TCPIP内核参数优化

懒人方案：决定24H不睡迎接中秋节——顺便修一修linuxuser.site邮件服务器的严重不可用问题

2026-08-09更新

明确一件事：FRP转发降速的根本原因你的稳定网络带宽并没有像IDC承诺的那样高！

通过iperf3 反复测速发现，NAS和Frp Server的链路速度中ipv4 udp是延迟和速度最佳的，因此我选择避免NAS frpc客户端使用ipv6连接 服务器。
其次，iperf3以不同限速条件测试还发现：
上行（本地→服务器）：在 50Mbps 时丢包率仅 0.038%，但达到80Mbps时丢包率骤升至 28%，说明上行安全极限约为 50Mbps。
下行（服务器→本地）：虽然极限能跑到 90Mbps 左右，但丢包率达 8.6%，为了稳定性调整限制在 70Mbps 以内。
一旦超出速率就面临30%的丢包率。为了避免高丢包对链路连接稳定性和重传概率的干扰，我选择切换到KCP模式，固定速率48Mbps，同时发现由于早前禁用TCP连接复用导致正常环境下访问cloudreve 短时间内静态资源和API请求会占用大量连接出现 frp备用连接池不足的问题。
2026-08-09 00:07:05.086 [E] [client/control.go:144] [da4d5ef29b0299e1] StartWorkConn contains error: work connection pool is full, discarding

因此tcp连接复用还是要开启的，当然也许理论上坚持手动调大预备连接池也能解决问题，但是考虑到国内运营商对家宽的连接数限制，最好降低连接数避免过高连接数触发QoS 影响链路稳定性。
同时为了降低对NAS G4600 CPU较为有限的资源占用，我没有采取vHost 代理模式，而是直接将cloudreve 的5212端口tcp通过FRP代理到HK Frp Server本地，然后原地建立Nginx反代，将TLS开销完全丢给HK Frp Server。
在经过上述调整后，测试上传的100MB文件上传进度均匀稳定，没有卡在100%，并且基本可以顶至预设的6MB/s限速最终稳定在5Mbps。（也符合百兆家宽普遍的上下行规律 QoS限制内的冗余值设置在40~50Mbps 实际机房链路预期为30~40Mbps。）

为什么同为UDP 谷歌宣传更好的QUIC反而不如KCP？

QUIC 强制 TLS1.3 加密握手开销大，且其默认的拥塞控制算法CUBIC基于丢包设计，一旦检测到丢包会激进地降低发送速率。家宽受运营商跨网和固有机房节点设备性能限制本就处于较高丢包率的网络环境中，CUBIC 会频繁地触发降速机制，导致吞吐量骤降无法像 KCP 那样快速重传，导致转发Cloudreve流量时出现严重的连接超时和假死问题。
具体配置分享如下：

Frpc 配置部署于 NAS 中国联通家宽

serverAddr = "149.104.5.21"
serverPort = 7000
auth.token = "null"

# 全局传输协议
transport.protocol = "kcp"
#transport.tcpMux = false

# ====== 代理列表 ======

# -------------------
# xfox.fun 主站
# -------------------
[[proxies]]
name = "xfox.fun"
type = "http"
localIP = "127.0.0.1"
localPort = 80
customDomains = ["xfox.fun", "www.xfox.fun"]
transport.bandwidthLimit = "6MB"

# -------------------
# linuxuser.site 主站
# -------------------
[[proxies]]
name = "linuxuser.site"
type = "http"
localIP = "127.0.0.1"
localPort = 80
customDomains = ["linuxuser.site", "www.linuxuser.site"]
transport.bandwidthLimit = "6MB"

# -------------------
# NAS 页面
# -------------------
[[proxies]]
name = "nas.xfox.fun 5212"
type = "tcp"
localIP = "127.0.0.1"
localPort = 5212
remotePort = 5212
#transport.useEncryption = true
#transport.useCompression = true
#如果你认为你的客户端设备性能较强你可以考虑开启压缩，但是个人不推荐同时启用压缩和加密（理论上显著增加链路延迟）
transport.bandwidthLimit = "6MB"

Frps 配置 部署于HK三网直连优化服务器

indAddr = "::"
bindPort = 7000
vhostHTTPPort = 按需随意
#vhostHTTPSPort = 8443

# 原 QUIC 监听端口（如果你不再用 QUIC，可以注释掉；保留也无妨，但本次客户端不用）
# quicBindPort = 7000

# KCP 监听端口（与 bindPort 一致，这样客户端无需指定额外端口）
kcpBindPort = 7000

auth.token = "null"
#transport.tcpMux = false
# 以下配置随意
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "你的用户名"
webServer.password = "你的密码"

Nginx 反代配置 部署于HK三网直连优化服务器

server {
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name nas.xfox.fun;
    http2 off;
    # SSL 证书路径按需随意，以下示例仅供参考
    ssl_certificate /root/www/all_xfox.fun/fullchain.pem;
    ssl_certificate_key /root/www/all_xfox.fun/privkey.pem;

    # ========== SSL 配置 ==========
    ssl_protocols TLSv1.2 TLSv1.3;  
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_ecdh_curve X25519:secp384r1;  
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_stapling on;
    ssl_stapling_verify on;
    # ====================================

    root /var/www/tv.linuxuser.site;
    index index.html;


    location / {
    # ========== 基础代理头 ==========
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    # ========== 后端地址 ==========
    proxy_pass http://127.0.0.1:5212;

    # ========== 超时设置 ==========
    proxy_request_buffering off;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    client_body_timeout 3600s;
    send_timeout 3600s;
    client_max_body_size 0;

    proxy_connect_timeout 75s;                # 连接后端超时（默认60s，适当延长）
    proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
    proxy_next_upstream_tries 3;              # 允许重试3次
    proxy_next_upstream_timeout 30s;          # 重试总时间限制
    proxy_http_version 1.1;
    proxy_set_header Connection "";

           }
}

写在末尾

TCP连接复用在运营商QoS环境下本身并不稳定，中途可能导致连接中断，进一步造成上传文件卡住假死的问题。因此你应该根据实际iperf3测试得到的低丢包率稳定的上下行带宽完成配置。理论上，TCP连接复用也并不能彻底解决连接池占满的问题，所以你也可以尝试关闭TCP连接复用并继续增大连接池数量到适宜水平。

开机F2 临时断电再拆了后盖把TiPlus 7100 装上关掉安全启动，先切换到显卡混合输出不然刚从3060换过来不然驱动必定水土不服花屏。
进Fedora后dnf reinstall akmod-nvidia xorg-x11-drv-nvidia-cuda然后再dnf update.
还得去改一下/etc/grub.d/里的自定义启动项配置避免硬盘识别顺序不符合预期造成无法正常引导。
依旧可以参考：解决Fedora41 Grub2 无法通过os-prober自动添加Windows启动项的问题 这次比较好的是os-prober识别到新机硬盘的Windows11了。
修改后重新sudo grub2-mkconfig -o /boot/grub2/grub.cfg
切到Windows11后上机先卸载联想辣鸡全家桶，留个Legion Zone即可。不值得探讨
9k啊，但愿尸体机拆散卖配件挂鱼能回点血。

有趣的是，我发现Fedora下y7000p这个电源键灯色和KDE 桌面环境里的性能选项是同步对照的，内核对此显然有一定适配。
然后我就想起来这个有点眼熟的项目：johnfanv2/LenovoLegionLinux 我之前用鸡哥的时候找开源替代就曾误打误撞找到过这个同类项目，没想到我也有用得到的时候。

后续

在备份原厂Windows11 镜像的时候发现原厂安装了一堆AI向的辣鸡软件，毫无例外的哪怕是本地运行的也需要登录。Dism++ 备份出来的67.6GB wim镜像里面估计不少是屎，但是当时没空单独处理了。 上传到阿里云盘进行云备份的时候发现上行很快6~8MB/s，下行只有200~1000KBps，这就我们抽象的广电卡，下载被QOS成屎，上行反而没人管。 如果短时间内大量传输，基站还会把广电从5G踢回4G，过几分钟又恢复5G。

时隔多年，我这台二手蛟龙5 76s终于炸鸡了。
前几天更新过驱动后，昨晚高负载打逃离塔克夫没注意打开游戏模式，然后直接弹出经典提示快速转到无限重启，随后经过数个小时的多次尝试确认设备可能因为CPU过热虚焊导致无法开机。
鉴于自己没有BGA焊台这些专业设备，这台二手鸡哥算是半步管材了，不过用了这么久也勉强算得上寿终正寝。
在Linux.do问了问佬友们意见，再让DS结合互联网评价的各待选热门款笔记本通病最终选择了联想的Y7000P。（没错这违背了我不买联想的原有计划。）
综合价格因素去淘宝一个非官方店铺9000软妹币下单了99新的Y7000P 2025 32G+1TB 的版本。

为啥打破预期买联想

坦白来说我本来首先考虑了机械革命的极光X和蛟龙16Pro，但是这俩通病太严重。高负载积热蓝屏+黑屏重启的问题这俩高概率中奖，还有设计散热垫厚度有问题导致过热USB断连的，扬声器杂音。
至于隔壁华硕天选也不遑多让天选Air 2025查到有键盘漏电问题，给人电麻了还没好好处理。天选6Pro 更逆天C壳鼓包+充电口松动+屏幕闪屏。
直接排除黑屏精灵及HP全系产品后，再看看隔壁戴尔，也是没逃过频繁蓝/黑屏，还有出现键盘失灵。
那么最后我选的Y7000P呢？它也不是一点问题没有，相反问题更恶心。R7000P我没敢买，怕积热重蹈覆辙，Y7000P 2025用上了14代酷睿，这代缩缸问题无需多言。
我敢选是因为现在是2026年，英特尔已经发了微码更新并且老奶奶过马路的联想也终于是在一片骂声里把微码更新慢慢同步上去了。
😂2026年买个好用的笔记本电脑这么难，我真的是没想到。
经济下行，产品质量也下行了，又或许只是以前就烂但是我不知道？

是的，你没看错。
祝距离猝死不远的你清明节快乐。😉

过完年后，公司又跑了几个人，也算情理之中吧，毕竟工资低事情又多。现在领导都在疯狂招人，可惜来的不多，留下就就更少，多是一个月只拿得到三四千块钱的学徒，一个月加满班干个20七八天也只能拿个5k出头。 又要上夜班，还是一周一倒班。
资本家把人变成了鬼。
我也在计划离职了，在这里待满了一年，大钱是肯定挣不到的，倒是加班把人累的半死，工作只能站着，最多也就是蹲着。坐一会儿他们觉得你闲了，便要把你喊去干别的活。
倒班更是恶心，每到夜班转白班便是下午六点上班第二天早上六点下班，回去还没怎么睡到了三点人还得到车间去，太可悲了，这不是一个21世纪的人应该过的生活。
在这样糟糕的经济环境下，赚钱很难，找好的工作也困难，工作是看不到未来的，只能听领导给你画饼，就这样的空气大饼也许我一辈子都吃不到嘴里去。
在论坛发了一下工作情况，大多数人都觉得挺糟糕的，是早该跑了。当然，也有不少网友提醒最好是骑驴找马先找好下家。
不管怎么样，我现在对CNC是感到恶心了，大多数CNC都要上夜班，其中90%都是12小时两班倒。
下一步计划找一个轻松些的工作，五天八小时是底线，挣钱少就少了，顾得上自己的生活便是，找到后就离职吧。
工作很重要，生活更重要，一切围绕适合的生活才能长久的维持工作状态。
晚安。
2026年3月3日更新：
领导今天来画饼，我趁机倒了捯苦水：小头目不让我们学新设备的操作，我觉得在公司看不到未来的希望。
于是喜闻乐见的看着小头们集体挨屌，当然这对于跑路大事不算不重要，毕竟这事已经意味着我把这群小领导得罪死了。
跑路终究还是要跑的，但是肯定要推迟一下把技术学到手再看情况，行就留下，不行就接着跑找下家。
只要脑子里有知识，不担心失业，实在没合适的活了大不了换一个厂还干CNC就是了。

因为某些缘故，不想在家过年，今天就打车回公司宿舍了。
在家待了两天也没白待，昨天借助AI在完全理清架构方案后通宵把Tranquil-Inbox-Ward （读作/ˈtræŋ.kwɪl/ /ˈɪn.bɒks/ /wɔːrd/ ChuanKuier YinBouSi WoerDe）模块化重构了，使用logprobs 计算softMax得到邮件属于三个类型的概率，结合针对性的Prompt强化了过滤效果，也不再硬性限制自己非得用RWKV模型了，换Phi3:mini提高英语（主要垃圾邮件语种来源）能力。
还好公司宿舍水电WI-FI不停，楼下食堂也有饭。
过年没事干的博友可以给我留言一起打游戏🐼,宿舍就我一个人，麦克风拾音效果极佳。
逃离塔科夫，CS2（官匹Only）, MC，反正玩啥都可以。