笔记
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/Shadowrocket 就是拉取不到配置？运营商按特征拦 + 客户端侧兜底
机场订阅链接在浏览器里能正常打开，可一放进 Clash、Shadowrocket 这类客户端，就拉取不到配置。GitHub issue 里一搜一大片，问题始终没被根治。更诡异的是：有人反映"同一链接同一设备，手机走几步换个基站网络又能订阅了"——同一个链接，换个网络表现就不同。这强烈指向运营商/网络链路在按特征拦截，而不是链接本身坏了。
先排除链接本身
浏览器直连能正常打开，基本排除订阅链接挂了、证书坏了这类问题——浏览器能访问说明 DNS、HTTPS 链路都是通的。剩下的变量就是"浏览器拉取"和"客户端拉取"之间的差异。
为什么客户端拉不到而浏览器能
客户端（Clash 系走 wget 类实现，Shadowrocket 同理）拉取订阅的请求特征和浏览器不一样：没有浏览器那么完整的 User-Agent、Accept 头。运营商或中间设备就靠这些特征来识别"这是订阅拉取请求"，选择性拦掉。有人怀疑是 wget 的 SSL 校验问题，但查证书链路又没毛病——更像是对"非浏览器特征流量"的随机拦。
先自己复现一把，把变量分开
在电脑上分别用带不带浏览器 UA 的 wget 拉一次订阅，对比结果：
wget -O - "订阅地址" # 不带 UA，模拟客户端
wget --user-agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -O - "订阅地址" # 带浏览器 UA
不带 UA 失败、带 UA 成功，基本就坐实是"按 UA/特征拦订阅请求"——那就从客户端侧想办法加请求头，或换网络。
客户端侧的兜底手段
- 换网络/换基站实测：既然不同网络表现不同，换个网络（WiFi 切流量、切基站）试一次，能拉就说明是你当前网络的链路问题，不是订阅问题。
- 加请求头/User-Agent：客户端拉取时带一个浏览器 UA 再试——部分客户端支持在订阅设置里加自定义 header。
- 订阅地址加 flag 参数：不少订阅支持在 URL 后加
&flag=clash这类参数，让服务端按指定格式返回，有时能避开特征识别。 - 更新时走代理：先开代理（或"使用内核代理/系统代理更新"），让拉取请求从代理出口走，绕开本地运营商对订阅域名的处理。
- 留意客户端版本回归：有案例是某客户端某个版本导入/删除订阅要重启才生效——先确认不是客户端 bug。
别忽略的另一类"更新不了"
如果是自动更新长期不触发而不是拉取报错：Clash Verge Rev 的自动更新默认"自动"条件（要满足触发条件）不满足时根本不会去更新。显式打开"使用内核代理/系统代理更新"，或手动点一次更新。
linux.do 上有个 Clash 更新魔戒订阅失败的案例，建议：关掉系统代理、换一个好节点重试。官方口吻很直白——长时间不更新就会这样，也可能"是被 q 了"（订阅域名被墙/被限）。这类先换节点、换网络重试，别反复点同一个失败操作。
总结：浏览器能开、客户端拉不到 = 先换网络/加 UA/走代理更新排除链路特征拦截；自动更新不触发就手动更新 + 开内核代理；多网络都失败才怀疑订阅源本身。
先量一下"拉取本身要多久"，超时比拦截更常见
浏览器拉一个几百 KB 的订阅文件没压力，但客户端内置拉取器往往有更短的超时（Clash 系默认十几秒）。机场面板生成大订阅、或你这路线到订阅域名延迟高时，客户端先撑不住放弃了。用 curl 把两种请求的耗时打出来对比：
time curl -sS -o /dev/null -w "code=%{http_code} time=%{time_total}s size=%{size_download}\n" "订阅地址"
time curl -sS -A "Mozilla/5.0" -o /dev/null -w "code=%{http_code} time=%{time_total}s size=%{size_download}\n" "订阅地址"
两次都能在几秒内返回 200 且 size 不为 0，才说明链路没问题；带 UA 明显快/成功、不带 UA 失败，才是特征拦截。
看服务端返回的状态码，别只盯"拉不到"
把客户端换成 curl 拉一次，重点看 code=：
403：很多面板对空 UA 或陌生 UA 直接拒，这不是运营商拦截，是订阅服务端的要求。给客户端加真实浏览器 UA 或面板要求的固定 UA 就能解决。200但 size 很小/为空：面板可能按 UA 返回了空配置或错误提示页，把响应体存下来看内容。- 连接超时或
000：才轮到"链路被拦"的怀疑。
给订阅 URL 加随机参数绕缓存与规则
某些网络设备/DPI 按完整 URL 做规则匹配，命中就掐。在订阅地址后拼一个不影响结果的参数（多数机场面板忽略未知参数），等于换了个"新 URL"，能绕开按精确 URL 记的拦截和中间缓存：
https://example.com/sub?token=xxx&rand=482913
原地址能拉、加了随机参数也稳定能拉，说明之前是"按 URL 特征"被搞，不是链接坏。注意别把面板鉴权参数弄丢，只追加不修改。
YAML 里 url 字段的 & 符号要加引号
订阅地址带 &flag=clash 这种参数时，写进代理配置的 proxy-providers.url 必须加引号，否则 YAML 把 & 当锚点语法，整个配置解析失败，表现同样是"导入/拉取不生效"：
proxy-providers:
airport:
type: http
url: "https://example.com/sub?token=xxx&flag=clash"
interval: 86400
这类属于客户端侧自己埋的雷，先排除再怪网络。