笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
Clash/FlClash 批量测速大量标 Timeout 但节点其实能用？先关"严格 DNS 覆写"
用 FlClash / Clash Meta 这类客户端，代理组里几百个节点，一点"批量延迟测试/刷新"，一大批节点全标 Timeout，红成一片。但你实际选中这些节点又能正常上网，单独测速有时也通。看着像节点全挂了，其实多数不是节点问题，是批量测速时 DNS 环节出了问题。
真凶：严格 DNS 覆写（Strict DNS Override）
有个真实 issue 复现得很清楚：开启"严格 DNS 覆写"时，批量测速大量误报 Timeout；关掉之后批量测速基本正常；重新打开又大量 Timeout。结论很直接——批量测速要一口气对几百个节点做延迟测试，DNS 覆写在这种高并发场景下会把很多请求卡住/带歪，表现成一片红。
怎么判断到底是不是它在捣乱（两步对照）
- 关掉"严格 DNS 覆写"，其它什么都不改，再跑一次批量延迟测试。如果原本一大片 Timeout 明显减少、大部分节点能测出延迟，基本坐实是它。
- 再重新打开跑一次，Timeout 又回来——那就是 100% 确定。来回开关对比两次，别嫌麻烦。
把"延迟测试"和"真实可用"分开看
- 客户端里的批量延迟测试大多走的是 TCP 握手/TLS 探测，测的是"端口通不通、握不握得上"，不代表真实网页浏览体验。
- 有些节点对测速类请求做了限速或拒绝，但正常流量没影响——于是出现"测速红、用起来绿"。
- 反过来测速全绿也不代表一定快：延迟高低取决于你到节点的实际线路质量。
节点特别多的场景怎么省心
- 机场订阅几百个节点，靠肉眼盯红绿没意义。开着自动测速/自动切换（延迟低于某个值才参与选线），让它自己挑，别手动逐个试。
- 全量测速的间隔拉长点，别频繁刷——全量测速本身也会让部分节点暂时无响应，看着像超时。
真·全红的排查顺序
系统时间不准 → 订阅过期/未更新 → 严格 DNS 覆写 → 被系统里其它 VPN/反诈类 App 抢了通道 → 换网络（WiFi 切手机流量）复测。按这个顺序走，多数能定位到具体环节，而不是整批节点真挂了。
一句话总结：批量延迟测试是"粗筛"，受 DNS、并发、系统状态影响很大；单点测速和实际使用才是"精判"。一片红别慌，先关严格 DNS 覆写再测一次，然后拿一两个节点实际打开网页验证。
批量测速在 Clash Meta 里到底是个什么动作
先把机制说清，不然很容易误判。FlClash 用的内核是 Clash Meta，界面上"批量延迟测试"和配置里的 UrlTest 策略组走的是同一套探测逻辑。一个自动选择组在配置里长这样：
proxy-groups:
- name: PROXY
type: url-test
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
timeout: 5000
url 是探活地址，timeout 是单次探测超时（毫秒），interval 是自动测速间隔。点"批量测速"时内核就按这套参数对组里每个节点发一次请求；FlClash 面板设置里那个"测速链接"同理，会盖掉组里的默认 url。
这样一拆就明白：一片红测的不是"这些节点能不能上你想上的网站"，而是"这些节点在你当前网络下能不能在超时窗口内连上那个固定探活地址"。探活地址若被 DNS 带歪、或它在部分节点路径上本身不通，整组一起红太正常了。
为什么严格 DNS 覆写会让并发探测全超时
严格 DNS 覆写打开时，内核里每个域名都要走 Clash 内置 DNS 的完整链路解析，命中远程域名还可能经代理再查一次。单点测速只有一两个请求，慢一点无所谓；几百个节点同时开测，等于几百路请求抢着做 DNS 解析和等远端回包，队列一堵，大量探测在 timeout 窗口内根本排不上队，就记成 Timeout。
不想关覆写又想少误报，两个折中：
- 把探活地址换成你当前网络能稳定访问的，比如
http://cp.cloudflare.com/generate_204，别死用默认的 gstatic。 - 拉大
timeout（比如 8000）和interval（比如 600），让内核别那么急，误报会明显变少。
全红时用一个命令快速证伪
curl -x http://127.0.0.1:7890 -sI -m 10 http://www.gstatic.com/generate_204
（7890 换成你 Clash 的混合端口。）随机挑两三个标红的节点，单独走代理 curl 一次探活地址。能返回 HTTP/1.1 204 就说明节点链路是通的，红纯粹是批量探测环节的锅，往 DNS/超时/并发方向查，别去折腾节点。