笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
sing-box 连 VLESS+Reality 报 verification failed？先别怪被墙，多半是 Xray 版本
客户端用 sing-box 连 VLESS+Reality 节点，突然启动就报：
reality verification failed
然后 sing-box 直接退出、整个代理起不来。老链接和新链接（换了 shortId/spiderX）都失败，而同一台服务端用 HAPP / v2ray 这类 xray 内核的客户端却一切正常。第一反应都是"节点被墙了"——但这个案例里，真凶不是墙，是服务端 Xray 内核升级后，和客户端 sing-box 的 Reality 握手对不上了。
为什么"客户端 X 能连、客户端 Y 不能连"最能说明问题
Reality 是同一套服务端同时服务多种客户端的协议。如果服务端本身被墙，那所有客户端都连不上，而不是只有 sing-box 挂、xray 系客户端全好。所以当现象是"部分客户端正常、部分不行"时，优先怀疑内核/协议实现兼容性，而不是被墙。
怎么定位：三步对照
- 别用 curl / openssl s_client 去测 Reality：Reality 协议本来就会拒绝非授权的握手，拿这些工具测必然失败，测不出真问题。
- 服务端本机回环对照：在服务端本机走
127.0.0.1回环、换不同内核的客户端做对照，排除"被墙"这个变量——如果回环下 xray 系客户端能过、sing-box 过不了，那就是客户端与服务端内核的兼容问题，不是网络被墙。 - 看服务端内核日志，别只看客户端报错。日志里 Reality 握手失败的记录长什么样、发生在哪一步，比客户端那句笼统的
reality verification failed信息量大得多。
真实案例的修复方向：服务端 Xray 降级/对齐
真实案例是在两个独立 VPS 上，把 3x-ui 从 3.5.0 降到 3.4.2、Xray 从 26.7.11 降到 26.6.27 之后，同一台 sing-box 1.12.17、同一份配置立即恢复——说明是服务端 Xray 新版内核的 Reality 实现变化，让旧客户端内核握不上。
类似地，有博主实测：mihomo（含 7 种 uTLS 指纹、开了 x25519mlkem768）和 sing-box 全失败，唯一能过的是同源的 xray-core。如果你服务端能选择内核版本，优先对齐成和客户端兼容的版本。
处理建议按顺序
- 先做回环对照，把"被墙"排除掉。
- 服务端（3x-ui/面板）查 Xray 版本，尝试回退到之前稳定的版本。面板里一般能看内核版本号、并有版本切换/更新入口，回退后记得关掉自动更新，别让面板又给你升回去。
- 客户端换同源内核（xray 系）试，能连上就坐实是内核兼容问题——这种情况说明节点本身没毛病，是版本组合没对齐，等两边版本重新兼容即可。
- 顺带提一个 V2bX 场景：sing 内核 vless reality 断流（连上后不定期断），服务端日志有
process multiplex connection ... file already closed、客户端偶发ERR_SSL_PROTOCOL_ERROR——这种是 mux 复用的坑，关掉 mux 往往就好了。断流和连不上是两码事，分开排查。
reality verification failed 在协议层面对应什么
Reality 握手时，客户端在 TLS ClientHello 的 SessionID 里塞了自己生成的一组身份数据（内含临时公钥和 shortId），服务端用自己的私钥去解。解不开、或解出来的东西对不上，服务端就回这句并断开。sing-box 启动立刻退出、屏幕上就这一行，其实是拿到了服务端拒绝的回执，不是它自己编的错误。
服务端 Xray 升级后一旦改了这段身份数据的编码或派生方式（0-RTT 会话恢复相关部分最常动），按旧规范组包的 sing-box 就握不上，而同源的 xray-core 客户端跟着服务端一起升级，自然没事。所以"xray 系客户端全好、sing-box 全挂"几乎必然是版本/实现错位——真被墙不会挑客户端。
服务端怎么快速查版本和回退
SSH 上服务器先看内核版本。3x-ui 的 xray 二进制路径基本固定：
/usr/local/x-ui/bin/xray-linux-amd64 version
改版本两条路：3x-ui 的"面板设置"里能直接填 Xray 版本号，保存后重启面板；或手动下载旧版二进制替换到上面那个路径，再 systemctl restart x-ui。替换前先备份原文件。回退完记得关掉面板的自动更新——3x-ui 有内核更新提示，手滑又给你升回去就白折腾。
客户端侧把日志等级开高看细节
sing-box 本地配置把日志开到 debug，能多看一层握手细节，比只盯着那句 verification failed 有用：
{
"log": { "level": "debug", "timestamp": true }
}
再对照服务端日志（xray 开 debug 能看到 reality 握手断在哪一步），基本能确认是 auth 解析阶段挂的还是后面 TLS 阶段挂的，提 issue 时也更有说服力。