ImgBox (imgly.net) 视频图床：昨晚把站点从"反复挂"调成了"稳跑"


说的是 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;

複製代碼

1.   - path: /api/*
2.     service: http://172.19.0.10:5245      # 直连后端
3.   - hostname: imgly.net
4.     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

探索精神可嘉

过来看看

感谢分享　勿忘提肛

看看怎么个事

感谢分享

感谢分享

感谢技术分享

感谢分享

这个好东西  感谢分享

感谢分享

感谢分享

原来您就是站长大佬呀,

技术贴，学习了，马住。

感谢分享

技术员

感谢技术站长

楼主技术宅，感谢分享。

没看看懂，发帖的是视频图床网站的管理员吗？如果是那就是大神显露真身啦

谢谢分享

感谢分享

感谢分享

感谢分享

毫安的啊

谢谢分享