你可能已经发现我的Mastodon上刷了一大串帖子，这正是刚才测试文章同步造成的。

同步使用了项目：FediverseSyncForTypecho 原始仓库为：jkjoy——FediverseSyncForTypecho
原仓库不支持使用代理完成网络请求，使得该插件在某些Mastodon站点被GFW屏蔽的情况下完全无法使用。
我的仓库把Release版本号刷到了1.6.5 主要增加了对http和socks5代理的支持。也是顺便测试借助DeepSeek 彻彻底底Vibe Coding了一回，确实很方便，花小钱办大事，比自己慢慢扣效率高太多了。

本次Vibe Coding使用Visual Studio Code搭配DeepSeek V4 for Copilot Chat

这个项目我自从看到GS在用就注意到了，当时就下载测试发现不支持代理试图自己添加代理支持（简单写死的）可惜学艺不精没一直扣完，太简陋不想公开最终拖到了今天。
我已经尽自己所能的审查了AI生成的代码，但是为了避免Vibe Coding可能潜在的混乱和污染问题，这个仓库的更新我不会推送到原始仓库，就让本项目作为我的个人试验品好了

具体更新如下：

Fediverse Sync for Typecho - 更新日志

版本 1.6.5 (2026-06-18)

新增功能

• SOCKS5/HTTP 代理支持

  • 新增可选代理配置，支持 HTTP 和 SOCKS5 两种代理类型
  • SOCKS5 使用远端 DNS 解析（CURLPROXY_SOCKS5_HOSTNAME），避免 DNS 污染
  • 支持代理认证（用户名/密码）
  • 适用于中国大陆等网络受限环境

重构优化

• HTTP 请求统一重构

  • 将分散在 Plugin.php、Action.php、Api/Sync.php 中的 6 处原始 cURL 调用集中到 Utils/Http.php
  • 新增 postForm() 方法，统一处理 Mastodon/GoToSocial 的表单编码 POST 请求
  • Header 去重处理，避免重复 header 导致 400 错误
  • 代理逻辑由 Utils/Proxy.php 集中管理，一处配置全局生效

调试改进

• 增强 HTTP 层错误日志

  • 请求失败时自动记录 URL、HTTP 状态码、cURL 错误号和错误描述、响应体预览
  • Proxy 应用代理时记录代理类型和地址，便于确认代理是否生效

文件结构

FediverseSync/
├── Utils/
│   ├── Proxy.php           # 增强：支持 SOCKS5+HTTP 代理类型选择
│   └── Http.php            # 增强：新增 postForm() + 代理集成 + 日志增强
└── Plugin.php              # 新增5个代理配置项

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

因为酷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正常识别到显卡。
此时设备管理器会显示一个微软基本显示设备实际上就是你那个没装驱动的显卡，正常安装驱动即可。

Linux内核遵循一切皆文件原则，Flutter开发遵从一切皆组件Widget的原则。

应用界面由组件与组件的嵌套堆叠构成，组件按照布局作用有布局组件（如Center，Column）和一般组件（常见Text，MD风格组件：Scaffold，floatingActionButton）

布局组件

Flutter提供的布局组件命名及其作用与前端CSS样式/Python Tkinter中的布局样式组件类似。
Center 是一个布局 widget。它接收一个子 widget，并将其放置在父 widget 的正中间。

StatefulWidget和StatelessWidget

按照状态区分则分为有状态组件 （集成自StatefulWidget）和无状态组件（继承自StatelessWidget ）
有无状态，主要区别在于是否需要在应用运行期间动态改变数据并更新UI。

无状态组件

属于不可变组件，创建后所有的属性、UI 呈现均固定不变。它不依赖任何随时间变化的数据
生命周期：简单，仅包含一个 build() 方法。
性能：性能开销低，不需要管理状态和触发重绘。
常见场景：静态文本（Text）、图标（Icon）、静态图片以及页面头部导航栏（AppBar）

class MyStatelessWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Text('这是一个无状态组件');
  }
}

有状态组件

特点：可变组件，在生命周期内可以持有、改变状态（State），并在状态改变时自动刷新、重新构建 UI。
组成部分：包含两个类，一个继承自 StatefulWidget，另一个继承自 State。UI 的逻辑和布局写在 State 类的 build 方法中。
状态管理：通过调用 setState() 方法通知 Flutter 框架数据已改变，从而触发 build 重新绘制界面。
常见场景：复选框（Checkbox）、输入框（TextField）、计数器、网络请求加载中状态等需要根据用户交互或数据更新而变化的 UI。

MyStatefulWidget extends StatefulWidget {
  @override
  _MyStatefulWidgetState createState() => _MyStatefulWidgetState();
}

class _MyStatefulWidgetState extends State<MyStatefulWidget> {
  int _counter = 0;
  // 函数命名下以划线开头表示该函数是一个私有函数，否则默认为公共
  void _incrementCounter() { 
    setState(() {
      _counter++; // 改变计数器数值并触发UI更新
    });
  }

  @override
  //重写build方法 
  Widget build(BuildContext context) {
  //返回一个可以检测手势的小部件：GestureDetector
    return GestureDetector(
      //onTap属性指定接受点击事件时调用私有函数_incrementCounter()
      onTap: _incrementCounter,
      child: Text('点击次数: $_counter'),
    );
  }
}

众所周知，境内三大运营商跨网以及境内外Qos问题非常严重，以至于使用Frp时都不得不受限于严重的丢包导致互联网速非常低下。
过去两天的测试发现，QoS不仅影响UDP，甚至TCP也会出现严重的丢包。
具体测试可见：佬友们，中国连不通来了。
这样极端的QoS使得即便用户通过VPN加密数据连接回家也无法获得更好的带宽。

既然本质是QoS的高丢包率导致的，我们就针对性考虑使用更好的拥塞算法以达到预期带宽。
更好的拥塞算法，近期毫无疑问指的是：Brutal 了

Brutal： 这是 Hysteria 自有的拥塞控制算法。与 BBR 不同，Brutal 采用固定速率模型，丢包或 RTT 变化不会降低速度。相反，如果无法达到预定的目标速率，反而会根据计算的丢包率提高发送速率来进行补偿。Brutal 只在你知道（并正确设置了）当前网络的最大速度时才能正常运行。其擅长在拥塞的网络中抢占带宽，因此得名。

BBR 的特性是慢启动和基于 RTT 变化的带宽估算 这一算法具有更好的普适性，因为设计为无须考虑双端带宽值，理论上可以更好的自适应调整到最高带宽。但是在高丢包环境下，BBR就显得有些无能为力了。

使用Brutal的首选自然是Hysteria2了，所以我的最终链路方案就是：
Client —> NAS hy2 Server -> NAS Cloudreve
测试证明这一选项能真正拉满本地上行：我将客户端设置为30Mbps UP后Hy2可以轻松的把向NAS的上传速率拉到30Mbps。

也就是说，使用Hy2 Brutal模式下可以真正把NAS的下行带宽充分利用，必经大部分时候客户端上行也不会超过NAS下行的100Mbps

数据说话

Shadowsocks-libre 直连回家的测试：

Hysteria2 Brutal算法直连回家测试 ：

这真的是爆杀了。
为了方便对比，下面是同客户端本地测试

2026-05-14

这很奇怪，因为我发现在我利用Hysteria2 猛跑了十几GB后整体网络情况（裸连）极大的好转了，连Frp转发在原有参数下速度都恢复了理想水平。我在上述测试之前已经重启了路由器和NAS，所以这种好转看上去和设备重启没有任何关系，唯一有关系的只是凌晨这个特殊的时间点和Hy2的使用。

在关闭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年买个好用的笔记本电脑这么难，我真的是没想到。
经济下行，产品质量也下行了，又或许只是以前就烂但是我不知道？