“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
Cloudflare 全球网络故障深度复盘：从服务降级到全面恢复的七小时
2025年11月18日，Cloudflare 全球网络遭遇重大服务降级，影响 CDN、防火墙、Dashboard 等核心服务，历时近8小时才完全恢复。
引言
2025年11月18日，全球最大的 CDN 与网络安全服务商 Cloudflare 经历了一次严重的全球性网络故障。从 UTC 时间 11:48 开始，到 19:28 正式宣布解决，整个事件持续了约 7 小时 40 分钟。这次故障影响了 Cloudflare 网络上的多个核心服务，包括 CDN/Cache、防火墙、Dashboard、Bot Management、Access、WARP 等 8 类服务，引发了 Hacker News 上的热烈讨论（2432 分，1650 条评论）。
本文基于 Cloudflare 官方状态页的实时更新，完整还原这次故障的时间线，深度分析其可能的技术原因，并总结这次事件给整个互联网基础设施行业带来的启示。
事件时间线全记录
第一阶段：故障爆发（11:48 UTC）
故障首次报告于 11:48 AM UTC。Cloudflare 官方状态页显示：
"Cloudflare is experiencing an internal service degradation. Some services may be intermittently impacted."
值得注意的是，官方最初的描述是"内部服务降级"（internal service degradation），而非外部攻击或配置错误。这表明问题起源于 Cloudflare 自身的内部架构，而非客户侧或第三方依赖。
此时受影响的服务列表已经相当广泛：
- Access（零信任访问控制）
- Bot Management（机器人管理）
- CDN/Cache（内容分发/缓存）
- Dashboard（控制面板）
- Firewall（防火墙）
- Network（网络层）
- Cloudflare One Client（统一客户端）
- Workers（边缘计算平台）
几乎涵盖了 Cloudflare 面向企业客户的所有核心产品线。
第二阶段：初步观察与局部恢复（12:00 - 12:53 UTC）
12:03 PM：官方仍在调查中。
12:21 PM：出现积极信号——
"We are seeing services recover, but customers may continue to observe higher-than-normal error rates as we continue remediation efforts."
这意味着部分服务开始自动恢复，但错误率仍高于正常水平。这通常暗示问题可能与某个配置的逐步传播或级联故障有关——部分节点可能已恢复，而其他节点仍在挣扎。
12:37 PM 和 12:53 PM：仍然处于调查阶段，没有新的实质性进展。
第三阶段：问题定位与局部措施（13:00 - 13:35 UTC）
13:04 PM：出现了一个重要的操作性决策——
"During our attempts to remediate, we have disabled WARP access in London. Users in London trying to access the Internet via WARP will see a failure to connect."
在故障处理过程中，Cloudflare 工程师主动切断了伦敦地区的 WARP 接入。这是典型的"隔离故障域"操作——通过主动牺牲局部服务来阻止故障扩散，为根因分析争取时间。
13:09 PM：官方确认问题已找到（Identified）——
"The issue has been identified and a fix is being implemented."
从 11:48 到 13:09，定位问题花了约 1 小时 20 分钟。对于 Cloudflare 这样的全球基础设施公司来说，这个速度在大型故障中属于正常范围。
13:13 PM：迎来第一个里程碑——
"We have made changes that have allowed Cloudflare Access and WARP to recover. Error levels for Access and WARP users have returned to pre-incident rates. We have re-enabled WARP access in London."
Access 和 WARP 服务恢复，伦敦 WARP 重新开放。这说明修复措施开始生效，但不是所有服务都同步恢复。
13:35 PM 和 13:58 PM：仍然专注于"恢复应用服务客户的服务"，CDN/Firewall 等核心数据面服务仍未完全恢复。
第四阶段：Dashboard 恢复与其他服务持续修复（14:22 - 15:40 UTC）
14:22 PM：仍处于修复中。
14:34 PM：另一个突破——
"We've deployed a change which has restored dashboard services. We are still working to remediate broad application services impact."
Dashboard 恢复，但"广泛的应用服务影响"仍在持续。这里的"应用服务"很可能指代的是 Cloudflare 的代理层（Proxy），即处理客户流量的核心数据面。
14:42 PM：官方首次使用"已修复"（resolved）一词——
"A fix has been implemented and we believe the incident is now resolved. We are continuing to monitor for errors to ensure all services are back to normal."
15:23 PM: 仍处于监控中，没有新的错误报告。
15:40 PM：出现了新的问题表述——
"The team is continuing to focus on restoring service post-fix. We are mitigating several issues that remain post-deployment."
注意这句话里出现了"post-deployment"（部署后），暗示这次故障可能由一次部署引发，而"post-fix"后的"multiple issues"表明修复过程中可能引入了新的副作用。
第五阶段：恢复期的新问题（16:04 PM）
16:04 PM：一个有趣的新影响出现——
"Bot scores will be impacted intermittently while we undergo global recovery."
Bot Score（机器人评分）开始受到间歇性影响。这揭示了一个关键的技术关联：Bot Score 依赖于全球网络的分布式学习和协同计算，当网络处于恢复状态时，不同节点间的数据同步可能不一致，导致评分结果不稳定。
第六阶段：逐步回归正常（16:27 - 17:44 PM）
16:27 PM：错误和延迟继续改善，但仍有间歇性错误报告。
16:46 PM：
"We continue to see errors drop as we work through services globally and clearing remaining errors and latency."
17:14 PM：错误和延迟已恢复正常水平，同时宣布将提供完整的故障后调查报告。
17:44 PM：官方确认所有服务运行正常——
"Cloudflare services are currently operating normally. We are no longer observing elevated errors or latency across the network."
同时，官方给出了一项重要建议：
"At this point, it is considered safe to re-enable any Cloudflare services that were temporarily disabled during the incident."
这意味着在故障期间，部分客户可能主动暂停了某些 Cloudflare 功能（如 WAF、Bot 管理）以规避风险。
最终解决（19:28 PM）
"This incident has been resolved."
官方宣布事件解决，但承诺会进行更深入的调查，并发布完整的根因分析报告。
技术深度分析
故障波及面分析
这次故障影响的服务面极广，从 CDN 缓存到防火墙、从 Workers 计算平台到零信任 Access 产品。这种跨产品的全面故障形态，通常指向以下几个可能的根因：
核心控制平面故障：Cloudflare 采用 Global Control Plane 架构来管理全球 300+ 数据中心的配置下发。如果控制平面出现问题，所有依赖统一配置的服务都会受到影响。
内部网络路由问题：Cloudflare 的网络架构高度依赖内部骨干网（Backbone）进行数据中心间的流量调度。如果骨干网出现 BGP 路由问题或内部链路拥塞，会引发多服务级联故障。
配置系统 Bug：从时间线中 15:40 PM 提到的"post-deployment"和"post-fix"措辞，以及故障先出现在内部服务（"internal service degradation"）来判断，这次故障极有可能由一次内部配置发布或代码部署触发。
资源耗尽/热点问题：某些关键服务（如 Token 验证服务、速率计算引擎）的底层依赖出现资源耗尽，导致请求队列堆积、延迟上升，进而引发大面积超时。
为什么 Bot Score 恢复最慢？
时间线显示，Bot Score 到 16:04 PM 仍在受影响，而 Access 和 WARP 在约 13:13 PM 就已恢复。这种恢复速度差异背后有深刻的技术原因：
- Bot Score 依赖于 Cloudflare 的机器学习模型，该模型的训练和推理分布在多个节点。在恢复期，模型参数在节点间的同步可能出现版本不一致，导致评分结果不稳定。
- Access 和 WARP 的逻辑相对简单，主要是认证和隧道建立，恢复起来更快。
WARP 在伦敦被主动切断的启示
在 13:04 PM，Cloudflare 主动禁用了伦敦的 WARP 接入。这看起来矛盾——WARP 是给最终用户使用的 VPN 服务，为什么在故障时优先处理它？
可能的逻辑是：伦敦是 Cloudflare 的重要网络枢纽之一，WARP 流量会消耗大量资源且可能干扰到内部修复操作。通过暂时切断 WARP 接入（尤其是非关键的消费者流量），可以释放带宽和计算资源，加速核心企业客户的恢复。
这种"先顾核心业务客户，再恢复消费者服务"的处理优先级，体现了 Cloudflare 企业级服务商的运营策略。
对技术社区的启示
1. 即使是最强的基础设施也会出问题
Cloudflare 作为全球最大的 CDN 之一（处理全球约 20% 的 Web 流量），其内部架构在冗余和容灾方面已经做到极高水平。但这次事件提醒我们：可靠的系统不是不会出错的系统，而是出错后能快速恢复、有清晰的应急预案和透明沟通机制的系统。
2. 状态页更新的节奏本身就是一门艺术
回顾整个时间线，Cloudflare 的状态页更新频率约为每 20-40 分钟一次，每次更新都包含：
- 当前状态（Investigating / Identified / Monitoring / Resolved）
- 已采取的行动
- 对用户可感知影响的具体描述
这种透明、准确、有节奏的沟通方式，在故障期间极大缓解了客户焦虑，值得所有技术团队借鉴。
3. 关于"安全地恢复"的细节
在 17:44 PM 的更新中，Cloudflare 特别指出"可以安全地重新启用故障期间暂时停用的服务"。这句话暗含了另一个技术细节：在重大故障期间，部分客户（尤其是安全敏感型客户）可能会收到 Cloudflare 的建议，暂时关闭部分功能以求稳定。故障结束后，重新启用这些功能必须谨慎进行，因为底层系统可能尚未完全稳定。
4. 网络基础设施的"单点风险"仍然存在
Cloudflare 的一大卖点是"Anycast"架构——全球共享同一 IP 段，用户请求会被路由到最近的数据中心。这种架构天然有故障隔离优势（一个节点挂掉不会导致全网瘫痪），但从服务商层面看，控制平面和核心数据面仍然存在逻辑单点。对于依赖 Cloudflare 的企业而言，多 CDN 或混合架构的容灾策略仍然不可完全放弃。
结语
截至本文撰写时，Cloudflare 尚未发布详细的根因分析报告（RCA）。但从时间线的技术细节我们可以推断，这次故障大概率源于内部系统的一次变更（配置或代码），变更触发了连锁反应，波及多个核心服务，而修复过程比预期复杂——正因如此，官方才会在 15:40 PM 用"multiple issues that remain post-deployment"这种描述。
对于整个互联网行业而言，这次事件的意义在于：它再一次以最直接的方式展示了全球互联网基础设施的脆弱性与韧性并存。"即使像 Cloudflare 这样以严苛工程文化著称的公司，也会在一个普通周二上午迎来长达八小时的全球性考验。"
我们期待 Cloudflare 的完整调查报告中透露更多细节。在此之前，这场故障的实时追踪记录本身就已成为研究全球基础设施运维的绝佳案例。