OpenList 卡顿优化方案 v2（含 CF 源保留 + 决策点 + 操作排期）

对象：容器 1Panel-openlist-9Tuc / 镜像 openlistteam/openlist:v4.2.5 / 1Panel 数据目录：/opt/1panel/apps/openlist/openlist/data 状态：2026-09-06 只读诊断完成。28pan / sakura Cloudreve 在用且保留（偶发 CF 假死）。此文件为待决策方案，未执行任何改动。执行前先在 1Panel 备份该应用（或至少 cp -a data）。

0. 诊断结论速览（v2 修正）

项	实测	结论
数据库	SQLite `data.db` 76KB，`x_meta`=0 行	只是配置库，无本地文件索引
缓存	3 源 30s，Local/139 = 0（从不缓存）	冷/大数据目录每次实时拉远端
搜索	meilisearch 指向 `localhost:7700` 但未部署	搜索实时遍历，无索引
出口代理	宿主设 `http_proxy/https_proxy=http://127.0.0.1:7890`、`ALL_PROXY=socks5://127.0.0.1:7890`（FlClash/Clash 类）	关键：openlist 访问 CF 源很可能经由该代理，代理抽风 → 源"假死"
CF 源真因	sakura DNS 只回 AAAA(2606:4700)+A(104.21)；宿主无 IPv6 默认路由；直连 TCP 443 秒通，但 HTTPS 时通时超时	双层问题：①无 IPv6 出口却拿到 AAAA；②CF 应用层对出口间歇限流/掐断 → 偶发假死
自身性能	本地 API <2ms；容器 CPU ~0%、内存 587MB	非资源瓶颈

一句话根因：OpenList 实时聚合多个远端源；其中 2 个 CF 源因"无 IPv6 出口 + 走抖动代理 + CF 偶发掐断"会间歇超时；数据越多 → 请求 CF 越频繁 → 越容易撞上假死窗口 → 整体越卡。

1. 方案总览（分 A/B/C 三档，可独立勾选执行）

档 A：保留 2 个 CF 源，做「绕代理 + IPv4 + 缓存」加固（推荐先做）

A1｜让 openlist 直连出网，不走 127.0.0.1:7890 抖动代理

影响面：仅 openlist 这一个容器。宿主其他程序仍走代理。
做法：
1. 1Panel 应用编排（compose）给 openlist 增加环境变量 NO_PROXY=* / no_proxy=*（对 Go 应用需确认其代理读取实现；openlist 基于 Go，多数库读 HTTP_PROXY/NO_PROXY）。
2. 若 openlist 镜像默认信任系统代理，则用 HTTP_PROXY= 置空或设 NO_PROXY=*。
收益：CF 源不再随 7890 抖动而假死；直连可稳定复用 CF 边缘（实测直连 TCP 秒通）。
风险：低。仅容器代理行为变化；无数据改动。

A2｜规避无 IPv6 出口却解析到 AAAA

根因：sakura DNS 返回 2606:4700:...（AAAA），宿主没有 IPv6 默认路由 → Go 解析优先尝试 v6 → network is unreachable 超时。
做法（任一）：
1. 首选：给这两个域名在宿主/DNS 层固定 A 记录（hosts 或内部 DNS 覆写为 104.21.x.x），或让 DNS 只回 A。
2. 或：临时确认 openlist 是否支持 ForceIPV4/ForceHostname 类配置（需查该版本）；若无则用 hosts 覆写最直接。
收益：消除一半以上"假死"来源。
风险：极低。不破坏源可用性，回滚=删掉 hosts 行。

A3｜保留源 + 调大缓存（按原表）

给 5 个在用源按下表把 cache_expiration 调大（28pan / sakura 保留，同样调大，命中缓存时即使源假死，目录也能秒开）：

挂载	driver	当前 cache	建议
/hi168s3	S3	30s	3600s
/189pan/oba	189CloudPC	30s	3600s
/chunyu_local	Local	0	600~3600s
/chunyu_139	139Yun	0	600~3600s
/星辰云盘	WebDav	30s	1800s
/drive.sakura…	Cloudreve V4	30s	3600s（源易假死→高缓存收益最大）
/28pan webdav	WebDav	30s	3600s（同上）

档 B：补搜索索引（meilisearch）— 中等改动，可选

部署一个 meilisearch 容器（同 1panel-network），改 config 指向它并配 api_key，重建索引。
效果：搜索从实时遍历 → 本地索引 <1s。
成本：多一个容器 + 首次全量建索引时间。

档 C：稳定性 / 维护（低风险顺手项）

设容器资源上限（1Panel 改 compose：cpus=4, memory=4GiB）。
清理旧日志（/ 76%）：data/log 50MB 旧档可删/轮转。
可选：给 2 个 CF 源配置更短的失败超时/重试，减少假死窗口内的等待。

2. 决策点（请逐项拍板）

#	决策	选项	我的建议
D1	A1 让 openlist 绕开 7890 代理直连？	① 直连（NO_PROXY=*） ② 保持走代理	①（直连 TCP 实测更稳）
D2	A2 对 sakura/28pan 做 IPv4 hosts 覆写？	① 做（固定 A 记录）② 不做	①（消除 v6 超时）
D3	A3 缓存表按上表统一调大？	① 全按建议 ② 只调 CF 两个源 ③ 自定义	①
D4	B 档是否部署 meilisearch？	① 是 ② 否	②（先做 A 档见效；B 可后续）
D5	C 档资源上限 / 清日志是否执行？	① 都做 ② 只清日志 ③ 都不	①
D6	执行顺序	A→C 分步、逐步验证	分步

3. 操作时间表（建议排期，均需维护窗口/低峰）

说明：每步之间隔开观察；改 compose/重启容器会造成 openlist 短时重启（秒级~数十秒）。

时段	操作	影响	回滚
T0（5 分钟）	1Panel 对该应用做备份/快照	无	—
T1（10 分钟）	A1：compose 加 `NO_PROXY=*` 并重启容器	openlist 重启	移除该环境变量重启
T2（15 分钟）	A2：hosts 覆写 sakura/28pan → IPv4；重启或 reload	同上	删除 hosts 行
T3（10 分钟）	A3：调大 5~7 个源 cache_expiration；WebUI 保存/重启	同上	恢复原值
T4（验证 15 分钟）	逐源列目录/搜索实测；看 docker log 错误量	无	—
T5（可选）	B 档 meilisearch（若 D4=是）	多一容器	停容器即可
T6（可选）	C 档资源上限 + 清日志	无业务影响	还原配置

总窗口预估：只做 A 档 ≈ 40 分钟；加 B/C ≈ 60–90 分钟。 建议执行时间：业务低峰（如深夜 00:00–02:00，当前时段流量最低时）执行 T1–T3，T4 观察半小时。

4. 验证命令（T4 用）

# openlist 自身
curl -sk -o /dev/null -w '%{http_code} %{time_total}s\n' http://127.0.0.1:5244/ping
docker logs --since 30m --tail 80 1Panel-openlist-9Tuc | grep -cE 'deadline exceeded|unreachable'
# 两 CF 源（容器视角需在容器内或 hosts 覆写后）
curl -4 -skI -m 8 https://drive.sakura.exp.dog
curl -4 -skI -m 8 https://www.28pan.com/api/webdav_server.php
# 容器代理是否已绕开（应无 7890）
docker exec 1Panel-openlist-9Tuc env | grep -i proxy

5. 回滚总则

所有改动均为容器配置/环境/hosts，不碰业务数据。
回滚 = 按表反向操作并重启；备份保留在 T0。
若某步验证不达预期，可单独撤销该步，不影响其余。

请按第 2 节 D1–D6 拍板；确认后我按第 3 节排期执行（可只先做 A 档）。

7.0 KiB Raw Permalink Blame History Unescape Escape