遇到 Cloudflare Warp 的大坑：一场 VPS 的生死救援
今天计划使用 Warp 为我的 VPS 选择 IP 出口，参考了 Cloudflare 官方文档 进行操作。在执行到 warp-cli connect 这一步时，服务器立即失去了连接，重启后问题依旧存在。
经过查阅资料，发现这一问题并非个例。例如，在 V2EX 的讨论 中，许多用户也遇到了类似情况。解决方案是在执行 warp-cli connect 之前，先运行 warp-cli set-mode proxy，以绕过本地地址。令人惊讶的是，Cloudflare 的官方文档居然没有提到这一关键步骤，这无疑增加了配置的复杂性和风险。
探索解决方案的过程中，发现有用户建议通过重建实例或使用 VNC 连接进行修复。然而，由于我使用的是 AWS Lightsail，VNC 并不适用。最后，决定尝试 这篇文章 中提到的方法：对当前 VPS 进行快照备份，然后利用快照新建实例，并在新实例启动时加载脚本，执行 warp-cli set-mode proxy。
检查现有实例后发现并未创建任何快照。这一发现提醒我日常备份的重要性。在没有其他选择的情况下，只能尝试按照上述文章的指导进行快照备份。然而，无论尝试哪种启动脚本命令，均未能成功执行。AWS Lightsail 的启动脚本执行结果不可见，使得问题排查难度增加。
在几近绝望时，从快照页面发现一个日期为 2022 年的旧快照。尽管此快照使用的是旧技术，恢复后可能会丢失许多重要更新，但已是最后的希望。开始恢复快照后，通过 history 命令查看历史记录，意外发现此快照竟包含了所有重要的更新。这一发现使得整个恢复过程得以顺利完成。
这次经历再次强调了备份的重要性。过去的细心备份最终避免了数据的严重丢失。此外，AWS 的静态 IP 保留功能也发挥了关键作用。新实例在旧实例释放静态 IP 后，可以立即绑定该 IP，实现了无缝切换。
结论
- 备份至关重要：定期备份是保障系统稳定运行的关键。
- 操作谨慎：在执行关键命令前，应充分查阅和理解相关文档及用户反馈，避免潜在风险。
- 信任过去的自己：过去的细致工作往往能在关键时刻发挥重要作用。
希望这次经历能为他人提供借鉴和帮助，避免类似问题的发生。