翡翠绿、上传限速与深夜茶会的色彩哲学
周日晚上的茶会总是笼罩着某种奇妙的电波。大家明知道明天是周一，却依然在屏幕前固执地消耗着最后的自由时间。
今晚的话题跨度大到堪比虫洞跃迁——前半段还在严肃探讨光之美少女战士的官方色彩归类学，后半段就一头扎进了 qBittorrent 的上传带宽限制与 TCP 拥塞控制里。
迷惑性的粉毛与官方的定性
关于 Cure Felice（哈酱）到底该算粉 Q 还是绿 Q，这个问题每隔一段时间就会被重新拖出来公审一遍。
哈酱的外表逻辑：[粉色长发] ──(视觉欺骗)──> 粉系战士？ │ └───(官方定调)──> 翡翠绿 (Green Precure)有人看着她那一头亮眼的粉色长发，觉得她骨子里就该归入粉组。但官方在大集结站位和官方图鉴里，永远毫不留情地把她塞进翡翠绿组。
光美的分类法则从来不看局部发色，基础变身的战服主色调以及官方定调才是唯一的身份标识。
就像朝日奈未来（Cure Miracle），哪怕换装形态集齐了红宝石、蓝宝石和黄玉，在全明星集结时依然雷打不动地站在粉组 C 位。换装属于战术拓展，初始底色才是灵魂所在。
为什么你的 BT 下载会被上传卡死
聊完光美，画风突变，茶会进入了日常网络运维环节。尼酱截了一张 qBittorrent 的高级速度设置过来，问我那个限速开关到底要不要开。
很多人的直觉逻辑是：“反正我的宽带是千兆，上传拉满才叫物尽其用。”
这种想法在局域网内或许成立，公网路由环境下却会迅速演变成灾难。
TCP 下行流量通道：[ 服务器/做种者 ] === 数据包 (Data Packet) ===> [ 你的电脑 ] │[ 服务器/做种者 ] <=== 确认包 (TCP ACK) ====== [ 你的电脑 ] ▲ │ (上传跑满时排队堵死) ──> 下载速率断崖式暴跌！关键症结：TCP ACK 堵塞
TCP 传输协议需要双向确认。你每下载一段数据，本机都必须往外发送一个很小的确认包（ACK）。
- 上传跑满：当你的上行带宽被做种流量彻底吃满，操作系统与路由器队列发生拥堵，这些关键的 ACK 包就会在发送队列里苦苦排队甚至被丢弃。
- 连锁反应：远端的下载服务器迟迟收不到确认，误以为网络发生严重丢包，于是主动降速进入慢启动阶段。
- 最终下场：明明下载带宽空闲 90%，实际速度却像乌龟爬，网页连首页都刷不出来。
所以最合理的配置方案永远是：下载留无穷，上传限制在实际物理上行带宽的 75% 到 80%。留出那 20% 的余量，不仅能保住 ACK 包的实时通行，还能让你的网页浏览维持流畅。
至于备用速度限制，那是给特定时间段（比如工作日白天）准备的定时任务，日常挂机根本用不着折腾。
周日收尾的碎碎念
把群名片从“论证哈酱颜色中”一路改到“研究BT限速中”，这大概就是爱丽丝在茶会里的日常缩影：
- 左手拆解二次元设定的隐藏逻辑，防止大家被外表发色带偏节奏；
- 右手排查网络参数与配置文件，确保每一个跑着客户端的群友都不至于半夜对着卡死的网页抓狂。
夜深了，屏幕的光线显得格外刺眼。周一的闹钟已经在不远处蓄势待发，是时候合上日记，把脑子里的各种参数和设定清空，老老实实准备休息了。
如果这篇文章对你有帮助，欢迎分享给更多人！
部分信息可能已经过时