说的是 ImgBox（imgly.net）—— 一个免费的图床工具，传图传视频传音频传 PDF，传完直接出链接。不用注册，不限速，链接可以直接贴到任何地方。
成绩单（Cloudflare 后台，最近 30 天）
最热资源 Top 20（近 24 小时，1031 万次请求）
1. 925,343 次
https://imgly.net/i/2026/09/29/22faa2ca.mp4
2. 624,725 次
https://imgly.net/i/2026/09/29/322cac8c.mp4
3. 563,540 次
https://imgly.net/i/2026/09/29/1bf99d8e.mp4
4. 555,101 次
https://imgly.net/i/2026/09/29/40dc99c2.mp4
5. 552,321 次
https://imgly.net/i/2026/09/29/e4350a7c.mp4
6. 550,604 次
https://imgly.net/i/2026/09/29/614e7ce6.mp4
7. 531,742 次
https://imgly.net/i/2026/09/29/931fd85e.mp4
8. 509,576 次
https://imgly.net/i/2026/09/29/c31b80e4.mp4
9. 499,500 次 https://imgly.net/i/2026/09/29/f8abd53e.mp4
10. 491,912 次
https://imgly.net/i/2026/09/29/b6b415e2.mp4
11. 490,212 次
https://imgly.net/i/2026/09/29/679716e3.mp4
12. 476,219 次
https://imgly.net/i/2026/09/29/8f0f97f8.mp4
13. 475,029 次
https://imgly.net/i/2026/09/29/9631fddd.mp4 14. 453,751 次 https://imgly.net/i/2026/09/29/77ecc4fc.mp4
15. 452,218 次
https://imgly.net/i/2026/09/29/3b035000.mp4 16. 437,504 次
https://imgly.net/i/2026/09/29/c244363a.mp4
17. 436,384 次
https://imgly.net/i/2026/09/29/66817145.mp4
18. 435,447 次
https://imgly.net/i/2026/09/29/7e6bcf84.mp4
19. 434,457 次
https://imgly.net/i/2026/09/29/f7638de0.mp4
20. 422,181 次
https://imgly.net/i/2026/09/29/ca629d39.mp4
| 指标 | 数值 |
| 请求数 | 22.8 亿 |
| 带宽 | 3.64 PB |
| 独立访客 | 3.66 万 |
| 缓存命中（请求） | 96.98% |
| 缓存命中（带宽） | 99.75% |
| 加密请求率 | 99.99% |
| 周期 | 请求 | 带宽 |
| 24 小时 | 8,954 万 | 122.67 TB |
| 7 天 | 5.84 亿 | 943.17 TB |
| 30 天 | 22.8 亿 | 3.64 PB |
3.64 PB 里，99.75% 是 CDN 在全球边缘节点直接返回的，根本到不了源站。真正回源到源站的，30 天只有 9.3 TB——平均 3.4 MB/s。
所以准确的说法是：CDN 扛住了 3.64 PB，源站只负责剩下那 0.25%，以及所有上传。
被访问最多的是视频：mp4 十六亿多次，其次是 jpeg、gif。视频占了七成以上的请求，所以下面几件事也都围着视频转。
引用
顺带一提：正是因为绝大多数请求压根不回来，才会出现昨晚那种怪事——监控全绿、源站几乎没压力，但站点就是不可用。问题出在那 0.25% 的回源路径上。
第一部分 · 先说结论
一、昨晚那场"灵异事件"
站点半夜开始时好时坏。传文件偶尔卡住，网页偶尔打不开。
但登进服务器一看，样样都正常：进程活着，CPU 没满，内存够，硬盘没报警，监控一片绿。
全绿，可用户说用不了。
这种最费劲。因为"看起来正常"和"真的正常"不是一回事。
后来找到了原因。网站前面有个网关，它接到请求之后要先排一个队，一个一个慢慢处理。这个队伍有上限，满员之后它就不再接活了——连专门用来问"你还活着吗"的检查接口都不接。
而队伍里的那些"来活"，处理完没被送走，就一直堆着，堆到满。
程序当时压根没设过"闲多久自动清理"这条规矩。
所以这不是偶尔抽风，是早晚必然会发生的事。
二、做了三件事
1️⃣ 让内部传文件不走网络
原来：用户 → Cloudflare → 隧道 → 网关 → 后端。隧道和网关之间，走的是一次真正的网络连接。
问题：这两层其实跑在同一台机器上，用的是同一份硬盘、同一个进程组。硬是绕了一圈网络，就像同一个人传文件非要发快递。
而且网络连接不是白来的——每建一条，系统都要给它分配内存和排队名额。几千条并发的时候，光"这些连接本身"就把机器的资源占掉了，真正要干的活反而排不进来。
现在：改成"面对面直接递"。连接数从 3586 条降到 1 条。
| 方式 | 排队长度 | 连接数 | 站点响应 |
| 改之前 | 4097（满） | 3586 | 2–7 秒 |
| 改之后 | 0 | 1 | 0.23 秒 |
2️⃣ 上传单独开一条通道
这条最反直觉，也最值。
这是图床，访客来取图取视频，下载（往下发）一直跑在 510 Mbps。而上传和下载共用一个出口。
于是：访客自己只传了几兆文件，却慢得像在挤早高峰。
监控上还完全看不出来——因为它确实"在传"，只是排在别人后面。
现在把上传的通道单独开出来了，下载再猛也占不满它。上传从"随时会卡"变成稳定。
3️⃣ 把传文件的大块调大
传大文件不是一口气发完，是切成小块分次发。每发一块，系统都要做一套固定动作（开文件、写进去、记位置、关掉、解锁）。
切得太碎，花在"做准备"上的时间比真正传数据的时间还长。
同一个文件，只改每块多大：
| 每块多大 | 发了多少次 | 花了多久 | 速度 |
| 1MB | 32 | 9.06 秒 | 3.5 MB/s |
| 8MB | 4 | 1.52 秒 | 21.1 MB/s |
一行后端代码没改，只调了参数，快了 6 倍。
第二部分 · 技术细节
1. 那个队列到底是怎么满的
/proc/net/tcp6 里 LISTEN 那一行的接收队列，直接反映积压了多少条连接：
| 时间 | 排队长度 | 未回收连接 | 站点 |
| 20s | 26 | 3 | 200 · 2.06s |
| 80s | 1447 | 4 | 000 |
| 120s | 2595 | 403 | 200 · 6.83s |
| 140s | 3204 | 754 | 502 ← 队列满了，站点死 |
| 160s | 0 | 0 | 200 · 0.36s ← 重启清空，秒回 |
队列上限 4097。填满之后，进程一个请求都不接——连 /healthz 都不接——而它同时满足：进程活着、CPU 6%、内存够、所有健康检查通过。
诊断这一条只要一行：
複製代码
docker exec root-caddy-1 sh -c "awk 'NR==2{print \$5}' /proc/net/tcp6"
健康的值是全 0。任何三位数就说明要出事。
根因是对端的连接没被回收（CLOSE_WAIT），而网关当时没有配置任何 server timeout，所以不回收是必然的，不是意外。
2. TCP 连接不是免费的
这是第 1️⃣ 那条改动真正的理由。换成 Unix domain socket（UDS）之后：
| 方式 | 排队长度 | 连接数 | 站点响应 |
| TCP（改之前） | 4097（满） | 3586 | 2–7 秒 |
| UDS（改之后） | 0 | 1 | 0.23–0.47 秒 |
中间不再产生任何 TCP 连接。没有连接要排队，也就没有"排队堵死"。
配置两行：
複製代码：nginx
listen unix:/run/gateway.sock;
複製代码
- - path: /api/*
- service: http://172.19.0.10:5245 # 直连后端
- - hostname: imgly.net
- service: unix:///run/gateway.sock # 其余走网关
複製代码
顺带量过同一时刻的对照：经网关的 /healthz 中位 541ms（209–572，方差巨大），直连的 /api/* 中位 215ms（209–218，几乎无方差）——回源那部分请求正把网关推着排队，API 绕开后纹丝不动。
3. 上传为什么会被下载拖住
tc qdisc 是 fq（公平队列），理论上会公平分配。但链路就那么宽：
| 方向 | 速率 |
| 下行（发给访客） | 510 Mbps |
| 上行（访客上传） | 挤在后面 |
发送缓冲区里堆满了待发的下载数据，上传的数据挤不进去。监控上完全正常，因为它确实在传。
顺便说说站上的两个东西
⚡ 临时快传
传完就走的文件用它。丢进去会给你一个 6 位取件码和一个链接，对方输码就能取，或者直接点直链下。
适合这几件事：临时把个文件甩给别人、不想注册账号、也不想让文件长期躺在自己的空间里。
用起来是：
[*]默认 24 小时自动删，最长可以设 7 天
[*]可以限定下载次数（比如只给 1 次，取完就没了）
[*]可以加密，别人没密码打不开
[*]有分享链接和直链两种形式，直链可以直接贴到任何地方
留言板
站上的匿名留言区。不用登录、不用注册，谁都能发，看得见谁发的。它不是评论功能，就是一个能互相搭话的地方。
我把它当成这篇的议题板——看到上面哪条做法不同意，或者你那边也遇到过类似的情况，直接发一条。
工具在这儿：https://imgly.net —— 拖进去就有链接，不用注册。传临时文件走「⚡ 临时快传」，想聊两句去留言板。
此贴由幽灵刺客重新编辑：2026-09-30 12:05