企业官网建设流程全解析

fastCRW（crw）是一个用 Rust 编写的轻量级 Web 抓取 API 引擎，提供与 Firecrawl 兼容的/v1/scrape、/v1/crawl、/v1/map接口，并内置/v1/search搜索端点和 MCP Server，是 Tavily、Firecrawl 的自托管替代方案。它的核心二进制空闲时只占用十几 MB 内存，意味着在一台 512 MB 的廉价 VPS 上，用一条 Docker 命令就能跑起一个免费的私有抓取 API——无需 Redis、PostgreSQL 或 RabbitMQ，没有按次计费的账单，抓多少都不花钱。

本文将带你完成从安装 Docker、启动容器、验证接口到配置认证与加固的完整流程。

为什么选择 Docker 自托管 fastCRW？

先说结论：如果你需要私有、可控、零按次费用的抓取 API，Docker 自托管 fastCRW 是目前门槛最低的方案。

它与传统抓取栈的差异在于资源占用：

官方 1,000-URL 基准测试显示，fastCRW 在内容恢复率（truth-recall）和延迟上均优于同场对比的 Crawl4AI 与 Firecrawl：

对自托管用户来说还有三个实际好处：

• Firecrawl 兼容：现有 Firecrawl 代码只需改一下 base URL 就能指向你的私有实例；
• 搜索开箱即用：Docker Compose 栈自带 SearXNG 元搜索引擎，/v1/search直接可用；
• JS 渲染自带：轻量级无头浏览器 LightPanda 作为 sidecar 一起启动，SPA 页面自动降级渲染。

一键启动：1分钟部署单个 Docker 容器

如果你的目标只是快速获得一个抓取 API（静态页面为主），这是最快的路径。

前置要求

• 一台任意发行版的 Linux VPS（Ubuntu 22.04/24.04 均可）
• 已安装 Docker Engine（curl -fsSL https://get.docker.com | sh即可）

拉取并运行镜像

docker pull ghcr.io/fastcrw/crw:0.16.0 docker run -d --name crw -p 3000:3000 --restart unless-stopped ghcr.io/fastcrw/crw:0.16.0

💡 生产环境建议使用固定 tag（如0.16.0）而不是latest，避免每次发版自动滚动导致行为变化。镜像基于debian:bookworm-slim，体积很小；构建细节见 Dockerfile。

验证服务状态

curl http://localhost:3000/health # {"status":"ok"}

看到ok就说明你的私有抓取 API 已经上线了。

完整方案：用 Docker Compose 部署「抓取 + 搜索 + JS 渲染」全栈

单容器适合起步，而仓库内置的 Compose 编排才是生产形态：一次up就得到三个协作的服务。

全栈服务一览

克隆仓库获取编排文件（仓库地址：https://gitcode.com/gh_mirrors/cr/crw）：

git clone https://gitcode.com/gh_mirrors/cr/crw cd crw docker compose up -d

启动的服务及端口分工如下（完整定义见 docker-compose.yml）：

几个值得注意的设计：

• 搜索端口不对外：searxng:8080只在 Compose 内部网络可达，搜索流量统一走/v1/search，攻击面更小；
• crw 会自动等待 searxng 健康检查通过再处理首个搜索请求，所以compose up后前 15–30 秒的搜索请求可能报timeout，属于冷启动正常现象；
• 渲染器与搜索后端的接线已经写死在 config.docker.toml 里（ws://lightpanda:9222、http://searxng:8080），你不需要手工拼环境变量。

可选：启用 Chrome 重渲染档位

LightPanda 足以应付大多数 JS 站点，但遇到重型 SPA 或 Cloudflare 质询时，可以加挂完整 Chromium：

docker compose --profile heavy up -d

该档位使用 Apache-2 许可的chromedp/headless-shell镜像，约 500 MB，按需选择。

从源码构建的注意事项

Compose 默认是build: .（本地交叉编译）。构建 Rust 工程峰值内存较高，请确保Docker 可用内存 ≥ 4 GB；受限时可串行链接降低峰值：

CARGO_BUILD_JOBS=1 docker compose build crw docker compose up -d

构建是一次性成本，运行镜像本身很小。如果你的 VPS 配置低，直接docker pull官方镜像并在 Compose 中把build: .换成image:更稳妥。

首次请求验证：/v1/scrape、/v1/search 与 /health

部署完成后，按官方推荐的顺序做三件事：先scrape一个真实目标，再验证一个search请求，最后跑一个有页数上限的小crawl。

# 1. 抓取单页为 Markdown curl -X POST http://localhost:3000/v1/scrape \ -H "Content-Type: application/json" \ -d '{"url":"https://example.com","formats":["markdown"]}' # 2. 搜索（由内置 searxng sidecar 提供） curl -X POST http://localhost:3000/v1/search \ -H "Content-Type: application/json" \ -d '{"query":"rust web scraping","limit":5}' # 3. 有界爬取（限 10 页，防止跑飞） curl -X POST http://localhost:3000/v1/crawl \ -H "Content-Type: application/json" \ -d '{"url":"https://docs.example.com","limit":10}'

这三个端点与 Firecrawl 的请求/响应结构保持一致，你的旧代码改个 base URL 即可切换。

生产前必做：API 密钥认证与密钥轮换

自托管默认不启用认证——服务器启动时会明确告警：若[auth] api_keys为空，任何能访问该端口的人都可以使用你的 API（见 crates/crw-server/src/main.rs）。暴露在公网前，请务必配置 Bearer 令牌。

方式一：环境变量注入（推荐，不改镜像）

在项目根目录创建.env文件（Compose 会自动读取）：

echo "CRW_AUTH__API_KEYS=$(openssl rand -hex 32)" >> .env

再为两个自带占位默认值的密钥生成真实值：

echo "SEARXNG_SECRET_KEY=$(openssl rand -hex 32)" >> .env echo "BROWSERLESS_TOKEN=$(openssl rand -hex 24)" >> .env docker compose up -d --force-recreate searxng

⚠️SEARXNG_SECRET_KEY与BROWSERLESS_TOKEN的仓库默认值是公开占位符，任何知道默认值的人都可能伪造会话或打开浏览器会话，公网部署前必须轮换。

方式二：挂载自定义配置文件

Compose 将 config.docker.toml 只读挂载到容器内，你可以复制一份并填入密钥：

[auth] api_keys = ["你的真实密钥"]

之后带密钥调用：

curl -X POST http://localhost:3000/v1/scrape \ -H "Authorization: Bearer 你的真实密钥" \ -H "Content-Type: application/json" \ -d '{"url":"https://example.com"}'

容器安全加固（已内置，无需额外操作）

官方 Compose 文件已对每个服务做了纵深防御，可以直接放心使用：

• read_only: true：根文件系统只读，恶意解析产物重启即消失；
• cap_drop: ALL+no-new-privileges:true：引擎不依赖任何 Linux capabilities；
• mem_limit: 2g/pids_limit: 512：防止失控 worker 拖垮宿主机；
• PDF 解析默认开启sandbox = true，每次解析跑在带内存上限的隔离子进程中。

更多加固细节（SSRF 防护、/metrics访问控制、CORS 白名单）见官方文档 docs/docs/self-hosting-hardening.md。

常用调优参数速查

fastCRW 的所有配置项都支持CRW_<模块>__<字段>环境变量覆盖，优先级高于配置文件。VPS 上最常用的几个：

两个实用场景：

• 3000 端口被占用：在.env中设置CRW_HOST_PORT=3055，无需改 Compose 文件；
• 前面挂了反向代理（Caddy/Nginx 做 TLS 终结）：设置CRW_BIND_ADDRESS=127.0.0.1，让 API 只监听回环地址，公网流量全部走代理。

注意config.docker.toml中全局限速默认是rate_limit_rps = 0（不限制），但每站点限速依然生效——这是出于礼貌爬取的设计，无需担心。

资源占用与 VPS 选型建议

官方在 50 并发请求下实测crw服务本身约 66 MB。加上 sidecar，不同档位的内存需求如下：

成本上，一台 $5/月（约 1–2 GB）的 VPS 即可覆盖标准档位。由于没有按次计费，月抓取量达到 1 万、10 万页时，费用始终是固定的 VPS 租金——这正是自托管 fastCRW 相对云 API 的核心经济优势。

常见问题（FAQ）

Q1：启动后/v1/search报 timeout 怎么办？冷启动正常现象。crw 会等待 searxng 通过健康检查，首次compose up后 15–30 秒内搜索可能不可用；确认服务端日志中打印的搜索后端地址即可。

Q2：能连接 AI Agent（Claude Code、Cursor 等）吗？可以。镜像内自带crw-mcp二进制，把 MCP 客户端指向你的http://vps-ip:3000并带上 API Key，Agent 即获得一个包月制的私有抓取工具，无按次费用。

Q3：JS 渲染会不会把 LightPanda 跑崩？Compose 中lightpanda服务配置了restart: unless-stopped，崩溃后自动拉起。复杂 SPA 会按 HTTP → LightPanda → Chrome 的失败链逐级升级，不会导致请求整体失败。

Q4：AGPL 许可对自托管有影响吗？个人/内部使用、不向第三方开放 API 时没有额外义务；若你把修改版 fastCRW 作为网络服务提供给第三方，需按 AGPL-3.0 §13 提供对应源码。许可细节见 docs/docs/self-hosting-hardening.md。

Q5：如何升级版本？重新docker compose pull拉取新镜像后docker compose up -d即可；建议每次升级前检查 docs/docs/changelog.md。

总结

用 Docker 自托管 fastCRW 的全部动作可以压缩成三步：

1. docker run -p 3000:3000 ghcr.io/fastcrw/crw:0.16.0—— 一分钟拿到私有抓取 API；
2. docker compose up -d—— 升级出「抓取 + 搜索 + JS 渲染」全栈；
3. 配置.env中的 API Key 与密钥轮换 —— 安全上线。

配合 512 MB–2 GB 的低配 VPS，你得到的是一套 Firecrawl 兼容、无按次账单、可接入 MCP 的完整 Web 抓取基础设施。更多端点细节可参考官方文档 docs/docs/docker.md 与 docs/docs/self-hosting.md。