笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本，起稿或二次编辑时都能随时切换，同一篇笔记想用哪种形态来记，都由你说了算。
md、txt、csv、json 这类纯文本则原样载入，不做多余加工。拿一张现成的表倒进来、改几笔、再导出去，等于白用一台免费的格式转换器。
要带走就在右上角点“下载”，可导出 PDF、Word、Markdown、Excel、TXT 等格式；列表卡片“⋯”菜单里，也有同样的下载入口。
在“工具”页点“＋ 上传工具”即可发布：填好名称与链接，再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用，比堆介绍实在。
要分发安装包就一并上传压缩包（ZIP、RAR、7Z、TAR.GZ，最大 35MB），别人在详情页一键下载；只放链接不带附件也可以。
工具按大家的收藏热度排序，好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”，这篇就只存在于你自己的账号里：不进列表、不进搜索、不上首页精选，也不会出现在任何公开的页面，链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容；想公开，去“发布”打开它，把“隐藏”的勾去掉再保存，之后编辑会默认保持原状态，不会悄悄变回公开。
不想公开、只想临时给人看：点“分享”生成一条带密码和有效期的链接，到期自动失效，你也能随时撤销。
你的内容会同时保存在多个副本上，系统定期做备份与完整性校验，再配合异地容灾机制：就算某台机器出问题，数据也不会丢，可以长期放心存放；特别重要的资料，仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上，更新、部署、回滚都很快，扩展性和稳定性都按长期运营的标准来设计（Built for reliability, designed to scale）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
OpenClash 一开，隔十几分钟全家断网、连路由 IP 都 ping 不通？按这几条查
OpenWrt 软路由（旁路由）上配好 OpenClash 后，每隔 12-14 分钟就断一次网——连路由 IP 都 ping 不通，非要重启路由才恢复。更邪门的是，重启后通过 Zerotier 的内网 IP 从手机数据能连上路由，进去看 OpenClash 显示一切正常运行，证明路由本身能上网，但其它设备就是连不上路由。这种"周期性全家断网"很典型，按下面几条查基本能定位。
按命中率排的检查项
- 关 IPv6：旁路由环境里 IPv6 是重灾区。插件里也提示"没用 IPv6 的最好关掉"。IPv6 流量绕过了代理分流逻辑，容易把路由自己的网络栈搞乱。
- 避开和光猫的网段冲突：如果软路由 LAN 段和光猫默认的
192.168.1.1撞了，会出各种诡异问题。有人把网段改成192.168.168.1这类避开光猫的段就稳定了。 - 检查是不是多个 DHCP 在跑：家里光猫、主路由、软路由如果同时开着 DHCP，设备会随机拿到错误的网关/DNS。只保留一个 DHCP。
- 别用手动固定 IP 造成 IP 冲突：固定 IP 配错会顶掉路由的地址。
- 连接数爆了：OpenClash 默认可能把大量连接都揽进代理。勾选"仅代理常用端口"+"仅代理命中规则流量"，减少无效流量对路由性能的冲击。
断网时的正确姿势：看日志，别靠猜
断网瞬间用物理连接（虚拟机终端、或给路由接显示器/串口）抓现场，比事后瞎猜有效得多：
logread | grep -iE "openclash|firewall|nft|dnsmasq"
看断的那一下是防火墙重载、还是 DNS、还是转发规则被重建。顺便看是不是周期性的——如果每次断网间隔非常规律（比如正好 60 秒左右一次），高度怀疑是某个 Watchdog/定时任务在捣乱。
一个隐藏很深的真实 bug：Watchdog 和防火墙规则竞态
OpenClash 在 iStoreOS/OpenWrt 的 fw4（nftables）环境有个已知竞态：Watchdog 每 60 秒检查一次 nftables 规则位置，触发防火墙 reload，在删除重建 @localnetwork 规则的那一瞬间，路由器自身 TCP 回包被错误重定向到 Clash 而丢失——症状是局域网内 SSH 连路由间歇性失败，而且"重启 OpenClash 或关闭 OpenClash 都无法恢复，只有 /etc/init.d/firewall restart 能修复"。
如果你的断网是"周期性 + SSH 路由间歇失败 + 重启 OpenClash 没用"，往这个方向查：手动跑一次防火墙 restart 看是否立刻恢复，是的话就是规则竞态在作祟，等 OpenClash 更新或调整 watchdog 相关设置。
先分清 fw3 还是 fw4
OpenWrt 23.05 前默认 fw3（iptables）、23.05+ 默认 fw4（nftables）。查 OpenClash 相关规则的命令体系完全不同，排查前先 uci show firewall 或看 /etc/config/fw4 存不存在确认版本，别拿 iptables 的命令在 fw4 上瞎试，试不出东西还浪费时间。
总结：周期性全家断网按「关 IPv6 → 避网段冲突 → 查多 DHCP → 限代理连接 → 看日志」的顺序来；SSH 路由间歇失败且重启 OpenClash 无效的，跑一次 /etc/init.d/firewall restart 验证竞态。
断网要是卡在固定分钟上，先查定时任务
12-14 分钟这个间隔不算整，但如果断网总发生在固定的时钟分钟上（比如每小时 :15/:45 前后），先怀疑有没有人/插件挂过 cron。OpenWrt 上定时任务就那几个地方：
crontab -l
cat /etc/crontabs/root
uci show system.@schedule 2>/dev/null
有些"定时重启拨号 / 定时清理"插件会写一条 firewall reload 或网络 restart。把它停掉再观察两个周期，不再断就是它在跟 OpenClash 打架。
抓"断的那一下"用时间戳关联日志
周期性故障最怕事后诸葛。在 OpenWrt 上开个带时间戳的循环 ping，把断点钉死：
while true; do date +%H:%M:%S; ping -c1 -W1 223.5.5.5 >/dev/null 2>&1 && echo up || echo down; sleep 5; done >> /tmp/netmon.log &
恢复后 cat /tmp/netmon.log 看精确到秒的断点，再去 /tmp/openclash.log 和 logread 里找同一秒前后的动作。每次 down 的时间点若都和 OpenClash 的 watchdog 重启或防火墙 reload 对齐，基本就锁定了，比瞎猜强太多。
OpenClash 自己的 watchdog 也可能是元凶
OpenClash 面板里有守护进程（watchdog）选项，它周期性检测网络/核心状态，判断"异常"就自动重启核心或重载防火墙。旁路由加某些 DNS 环境下，它会把"暂时解析慢"误判成"核心死了"，于是定时重启——表现正是周期性全家断网，而路由本身其实活着。进面板把 watchdog 关掉或把检测间隔拉长，观察是否还断。