笔记
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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
Redis 裸奔公网被种了矿：服务默认绑 0.0.0.0 的教训
一台云主机出了事，最后定位到根因是 Redis 没设密码、还绑在 0.0.0.0 上，等于把 6379 端口裸奔在公网，被扫描器扫到之后用未授权访问写了个 cron 任务，把机器变成了矿机。这个剧情在安全圈几乎算经典案例了，但真轮到自己身边人头上，处理过程还是值得记一笔。
当时现象是 CPU 忽高忽低，crontab -l 里多了一条自己不认识的记录，内容是从某个地址下载脚本然后执行。顺着查才发现服务器上跑着 Redis，redis.conf 里 bind 写的是 0.0.0.0，protected-mode 不知什么时候被人改成了 no，requirepass 是空的。等于任何一个能连到 6379 端口的人，都可以 redis-cli 连上去执行命令。Redis 未授权的老漏洞利用里，最出名的一招就是写 crontab，把反弹 shell 或者挖矿脚本写进定时任务。虽然那条 cron 后来被清了，但机器已经被种过东西，不敢再用，最后是重装的。
教训第一条：默认别绑 0.0.0.0。像 Redis、MySQL、MongoDB、Elasticsearch 这类带数据或者能执行命令的服务，默认监听都该收敛到 127.0.0.1，只有明确要给局域网其他机器用的时候，才绑内网 IP。查当前监听最直接的是 ss -lntp，看每个端口监听在哪个地址上，凡是 0.0.0.0:6379、0.0.0.0:3306 这种就要警惕，结合云厂商的安全组看是不是暴露到公网了。
改法很简单。Redis 在 redis.conf 里把 bind 改成 127.0.0.1，需要给内网别的机器访问就写成 bind 127.0.0.1 192.168.1.10，只写需要的那几个内网 IP，别图省事写 0.0.0.0。MySQL 在 my.cnf 里配 bind-address = 127.0.0.1，只有本机用的话甚至可以 skip-networking 直接关掉 TCP。改完记得重启服务再 ss -lntp 确认一遍。
教训第二条：Docker 发布端口有个隐蔽坑。docker run -p 6379:6379 这种写法，默认是绑在 0.0.0.0 上的，跟容器里 Redis 自己 bind 什么没关系。我之前有台机器在容器里跑 Redis，以为容器里配了 bind 127.0.0.1 就安全，结果 -p 把端口直接暴露到宿主机所有网卡，一样裸奔。要只给本机用，得写成 -p 127.0.0.1:6379:6379，compose 文件里对应 ports 写 "127.0.0.1:6379:6379"，这样宿主机之外根本连不到。这个细节我后来每次写 compose 都会确认一眼。
教训第三条：安全组和本机防火墙是两层，别只靠一层。云厂商的安全组如果放行了 0.0.0.0/0 的 6379，本机 Redis 绑 0.0.0.0 就彻底暴露；反过来安全组没放行，本机绑 0.0.0.0 暂时也进不来，但哪天安全组规则一改或者有人开了个全放行的口子，裸奔的服务就完了。所以稳妥做法是服务本身绑内网，安全组只放 22、80、443 这类真正要对外的端口，两层一起收。
顺带说下我现在的习惯：新装机器先 ss -lntp 看一眼都有谁在听，再对照安全组过一遍，凡是 3306、6379、27017、9200 这些数据库端口出现在公网监听上，一律先绑回内网再说。改默认端口那套（把 6379 改成 16379 之类）我也试过，后来发现意义不大，端口扫描是全量扫的，改端口只挡不会扫的脚本，挡不住有心人，真正有用的还是别让它出现在公网上。Redis 真需要远程访问，宁可走 SSH 隧道或者只绑内网，也别把带写能力的服务直接晾在公网上。
再说几个当时排查容易漏的点。Redis 除了 6379，开了集群或者 Sentinel 的话还有 16379、26379 这些端口，改配置别只盯着主端口。Redis 的 protected-mode 机制本意是好的——没设密码又没显式 bind 的时候，只允许本机回环访问；但很多人为了局域网访问图省事把它设成 no，又没加 requirepass，等于亲手把保护关了。正确姿势是 protected-mode 保持 yes，需要远程访问就显式 bind 内网 IP 再配个随机串密码，别用短密码。清理时我还顺手把云安全组里对 0.0.0.0/0 放行 6379 的那条规则删了，因为就算 Redis 绑回内网，安全组那条大口子留着，下次别的服务裸奔照样出事。数据库类服务的公网端口，我的原则是能不开就不开，真有需要就 SSH 隧道或者只对特定 IP 放行，别嫌麻烦。