Wayback 下载：按所需精力排出每一种方法

站点消失了。主机把它清空了，备份里只有一堆没什么用的 tar 包，地球上仅存的那份副本就躺在 Wayback Machine 里。现在你需要一次真正能用的 wayback 下载，而达成目标的方式有四种。它们从两分钟的浏览器小技巧，到帮你全自动搞定一切的服务都有，之间的精力鸿沟大得惊人。下面就逐一介绍每种方法，按它们会消耗你多少小时来排序，顺便讲讲那些落地页上绝不会告诉你的翻车点。

一次 wayback 下载到底能拿到什么

Wayback Machine 并不存储你的站点，它存储的是响应：每条 URL 一次抓取、一个瞬间。你的首页可能有一万次抓取记录，而隐私政策只有两次，分别在 2014 年和 2019 年。所谓 wayback 下载，就是把这些存储的响应按 URL 一条一条取回来，再拼成一个大致像原站的东西。

由此会引出两个后果。第一，爬虫从未看到过的东西就永远没了：没有数据库，没有 PHP 源码，没有后台，登录墙后面的任何东西都别想拿到。第二，你拉回来的每个文件都冻结在一个你无法选择的抓取时间点。把 2016 年的样式表配上一份 2021 年的首页，整个站点看起来就像一封勒索信，因为本质上你组装出的就是这么个东西。

任意一个快照页面的日历视图都能直观看出这一点。蓝点表示抓取，之间的间隔在冷门页面上可能长达数年。所以在挑方法之前，先定一个目标日期：选出站点看起来最符合你需要的那一年。在这之后的所有决定, 抓哪些快照、信任哪些资源, 都会变得更轻松。

方法一：用浏览器保存单个页面

打开快照，按 Ctrl+S，选择“网页，完整”。搞定。就一个页面而言，这是世上最快的 wayback 下载方式。但只要超过十页，它就变成一种自我折磨，所以要懂得适可而止。如果浏览器把什么东西搞坏了，打开开发者工具，在网络面板里找到资源 URL，逐个单独保存即可。

• 使用 id_ 小技巧：在快照 URL 的时间戳后面插入 id_，就能拿到与抓取时一模一样的原始 HTML，没有 Wayback 工具栏，也没有被改写过的链接。
• 保存下来的页面其资源是热链接回 web.archive.org 的。离线打开后，一半图片会消失，除非你之前也把它们显式保存了下来。
• 保存前先在日历视图里确认抓取日期。抓错年份是新手最常犯的错误，而存档站点很少会给你提示。

方法二：wget 方式的 wayback 下载脚本

经典做法是让 wget 以镜像模式指向一个存档 URL：wget --mirror --page-requisites --convert-links https://web.archive.org/web/2019/https://example.com。wget 会顺着 Wayback 注入的改写链接跳转，让请求始终留在 archive 内部，而 --page-requisites 会把每个页面所需的 CSS、JavaScript 和图片都拉下来。

对于一个 40 页的宣传站，一个晚上就能跑完。但请把这个晚上用来盯着它。archive.org 会限流过于激进的客户端，所以两次请求之间要加 --wait=2，并且脚本卡住时别意外，可能得重跑几次。用一条 --reject 正则把 wget 锁在目标时间戳附近，可以避免它跑到二十年前后的无关快照里去闲逛。

你最终拿到的，是一堆仍带着 Wayback 工具栏、每个资源 URL 里都塞着时间戳、并且在爬虫漏掉文件的地方静默缺损的 HTML。把这一坨东西变成一个可部署的站点是另一个工程，而人们经常忘记把这部分时间排进日程。

方法三：基于 CDX API 写脚本

当盲目爬取不够用时，就直接对接源头。CDX API 会返回一条 URL 或一个域名下所有抓取记录的机器可读列表：web.archive.org/cdx/search/cdx?url=example.com/*&output=json&filter=statuscode:200&collapse=urlkey。这一次请求的含金量就超过跑一小时 wget，因为它在下载之前就先告诉你到底有哪些东西存在。

用 Python 或 Node 写的循环很直接：读列表，给每条抓取记录加上 id_ 后缀去拉取，写到磁盘，礼貌地 sleep 一下。威力在于筛选条件。可以按年份或 MIME 类型过滤，再用 collapse=digest 去重，这样每个唯一的文件只抓一次，而不是重复抓四十次。

我做取证类工作时最常选这个方法，比如把某家公司发布过的所有 PDF 都拉出来，或者把某个目录按某个具体日期重建出来。它同时也是一个货真价实的编程项目：为一个中等规模的站点写一个稳妥的脚本，要花一个周末去写、测，并在凌晨两点连接断开后重跑。

方法四：自动化的还原服务

第四个选项是完全跳过手工劳动。专为这种活而生的服务会去查询存档，下载所有抓取到的文件，去掉 Wayback 浏览器壳，修复内部链接，最终交给你一个能跑的站点，而不是一地碎片。

Restorix 是我向客户推荐的那一家。光是免费估价就值得点进去：在你掏一分钱之前，它会展示确切的存档文件数量、总大小，以及一个锁死的价格。还原按文件计费，首个文件免费，如果还原或部署失败，款项会自动退回到你的余额里。不用提工单，不用和客服扯皮。

和 DIY 路线相比，这笔账很直白：花一笔小额固定费用，换走你的周末、被限流的痛苦，以及清理脚本。我最近评估过的三单活儿，费用都低于客户两个计费工时的成本。

那些毁掉一次 wayback 下载的错误

• 忽略查询字符串。/page.php?id=12 和 /page.php?id=13 是不同页面的不同抓取。漏掉它们，一个 WordPress 博客或 phpBB 论坛的内容会少掉一半。
• 随意混用时间戳。一份 2018 年的首页配上一份 2013 年的 CSS，看起来就像一张坏掉的复印件。先定目标日期，并尽量保持在前后几个月之内。
• 忘记其他主机名。挂在 cdn.example.com 或 assets.example.net 上的图片属于不同的 URL 前缀，单独的本站查询根本看不到它们。
• 盲目信任历史覆盖范围。archive 曾长期遵守 robots.txt 的排除规则，所以某些站点的整片区域其实从未被抓取过。
• 以为最新的抓取就一定最好。新的未必更好。被黑、被停放或被重定向之后再抓到的快照，价值远不如两年前一份健康的快照。
• 保存了被改写过的 HTML。如果不加 id_ 后缀，Wayback 工具栏和 archive.org 的链接会被烤进每一页，之后总得有人再把它们剥掉。

为你的站点挑对方法

来一个真实场景：客户一个 300 页的营销站彻底没了，备份也不存在。方法一要你手动保存 300 次，按十小时算。方法二要一个晚上再加一天的清理。方法三要一个周末，前提是你本来就会写代码。方法四是一笔从一开始就知道的固定费用，换回来的是清理干净、链接重整、可直接部署的站点。每小时一算，账并不复杂。

我做了多年还原活之后总结的规则：只要站点还需要重新活过来，直接走方法四，因为这正是 Restorix 的存在意义。如果只是为了取证或留念要一个页面，那就方法一。中间那两种，是给享受过程而不是看重结果的人准备的。