OpenWrt

WAN6 已拿到 IPv6 地址，但在 OpenWrt 上 ping 公网 IPv6 时，立即返回： ping: sendto: Network unreachable 最后发现，现场存在一条与 mwan3 一致的带标记不可达规则。删除它后，IPv6 恢复。这个案例说明：看到了默认路由，也不代表实际流量一定会使用它。 本文记录一次实际排查。公网源地址已替换为文档示例地址；设备名、规则优先级和 mark 应以自己的设备为准。卸载命令适用于使用 opkg 的 OpenWrt。 默认路由存在，为什么仍然不可达 最初排查时怀疑默认路由缺失，随后输出已经能看到带源地址条件的默认路由： default from 2001:db8:1234:5600::4 via fe80::1 dev eth1 proto static metric 512 pref medium default from 2001:db8:1234:5600::/64 via fe80::1 dev eth1 proto static metric 512 pref medium 排查中还临时补了一条普通默认路由： ip -6 route add default via fe80::1 dev eth1 metric 1024 但 ping 仍立即返回 Network unreachable。此时继续叠加默认路由已经没有帮助，需要检查实际选路和策略规则。 先确认上游网关可达 ping -6 -I eth1 -c 3 fe80::1 三次请求全部收到回复，说明 OpenWrt 到上游网关的链路本地通信正常。IPv6 使用 fe80:: 开头的链路本地地址作为下一跳是正常现象；这里指定设备，是为了确定该地址属于哪条链路。 ...

使用 rclone 将本地文件通过 OpenList 的 WebDAV 接口上传到夸克网盘时，OpenList 的内存占用可能明显增长，甚至触发容器 OOM。排查后发现，关键在于夸克驱动上传前的整文件缓存，以及容器统计中包含的文件页缓存。 本文分析针对 OpenList v4.2.7、普通夸克驱动、Docker 和 cgroup v2。其他驱动、其他版本应重新核对实现。 夸克上传为什么需要缓存 OpenList 的 WebDAV 入口把 HTTP 请求体包装成文件流，再交给目标存储驱动。这一步本身不统一将整个文件读入内存。 但普通夸克驱动会先取得文件的 MD5 和 SHA1。WebDAV 上传路径没有向文件对象提供这两个哈希，因此驱动调用： stream.CacheFullAndWriter(&up, io.MultiWriter(writers...)) 这个调用在计算哈希的同时，缓存完整文件。随后，驱动向夸克提交预上传和哈希请求；如果不能秒传，再从缓存中读取数据、分片上传。 哈希计算可以使用很小的内存，真正占空间的是为后续回读而保留的文件内容。 即使夸克支持分片上传，也不代表前面的整文件缓存不存在。 v4.2.7 的 HybridCache 有内存和文件两类后备方式。允许使用内存时，会尝试扩充缓存，分配受限后再切换至文件；其中部分内存通过匿名 mmap 管理。因此不能仅靠调整 Go GC 参数约束所有缓存占用。 rclone 的 --transfers 控制同时传输的文件数。两个文件并发上传，意味着两份整文件缓存可能同时存在。降低 rclone 自身的 --buffer-size 并不能直接限制 OpenList 进程中的这部分缓存。 为什么有临时目录仍占用内存 例如： "temp_dir": "data/temp" 这只指定临时文件保存位置，不强制每次缓存都写入磁盘。该相对路径还要结合 OpenList 的工作目录、Docker 挂载判断实际位置。 此外，v4.2.7 的缓存扩容检查使用系统可用内存统计，没有在该检查中直接读取容器的 memory.max 和 memory.current。这使得宿主机尚有空闲内存时，容器仍可能先撞上自己的内存限额。 改用磁盘临时文件 先暂停上传并备份配置，在 config.json 顶层设置： "min_free_memory": -1 这是字段片段，不是完整配置文件，修改时应保留其他内容和合法的 JSON 结构。 ...