企业官网建设流程全解析

反爬对抗指南：degoog的4种出站传输——curl-impersonate、FlareSolverr与真实浏览器会话

【免费下载链接】degoogSearch engine aggregator with a comprehensive plugin/extension system项目地址: https://gitcode.com/gh_mirrors/de/degoog

degoog是一款自托管的开源搜索引擎聚合器，它把多个搜索引擎的结果汇总到一个页面。为了让它稳定地抓取各家引擎，degoog 内置了反爬对抗的核心组件——出站传输（Transport）：从fetch、curl、curl-impersonate、自动回退，到官方扩展FlareSolverr与真实浏览器会话，共 4 类对抗手段。本文将带你快速看懂每种传输的原理与选型方法。

为什么搜索引擎聚合器需要"反爬对抗"？

degoog 的工作方式是：服务端代表你去查询各个搜索引擎。而现实是——被查询的网站会反击。

"Transports exist because the sites we query fight back." 传输之所以存在，是因为我们查询的站点会反击。 —— AGENTS.md

常见的反击手段包括：

• 🚫TLS 指纹识别：通过加密握手特征识别出"你不是浏览器"，直接返回 403；
• 🐌限流：短时间多次请求返回 429；
• 🧱Cloudflare 质询页：要求执行 JavaScript 挑战才能放行；
• 🔄间歇性 502/503：对可疑客户端返回代理错误。

degoog 的解法是把"发请求的方式"抽象成可插拔的传输层，你可以按引擎单独指定用哪种方式出站。

四种传输总览：一张表看懂

degoog 内置了 4 个传输，注册在 src/server/extensions/transports/registry.ts：

此外，FlareSolverr和真实浏览器会话作为扩展生态中的高级选项，覆盖更极端的对抗场景。

在设置页切换传输

所有传输都可以在设置页的"传输"标签中查看与管理，界面把内置传输和自定义传输分组展示，逻辑见 src/client/settings/transports/tab.tsx：

每个引擎还支持outgoingTransport配置项，让你按引擎单独指定出站方式——比如给某个反爬严格的引擎单独指定 curl-impersonate，其余引擎继续用最快的 fetch。

传输一：curl-impersonate —— 伪装 Firefox 的 TLS 指纹

很多反爬系统不看你的 HTTP 请求头，而是看TLS 握手指纹（加密套件顺序、扩展列表等）。普通 curl 的指纹和 Firefox 差异巨大，一眼就被识破。

curl-impersonate是一个魔改的 curl，它能逐字节复刻 Firefox 的 TLS 指纹。degoog 的实现在 src/server/extensions/transports/builtins/curl-impersonate/index.ts：

"Uses curl-impersonate to mimic Firefox TLS fingerprints. Helps with endpoints that block based on TLS fingerprinting." 使用 curl-impersonate 模拟 Firefox 的 TLS 指纹，帮助应对基于 TLS 指纹封禁的端点。

它还做了两件贴心事：

• 启动时探测二进制：找不到curl-impersonate-ff可执行文件时会在设置页明确提示，而不是默默失败；
• 独立 Cookie 命名空间：会话 Cookie 存放在transport:curl-impersonate:cookies下，与其他传输互不污染。

一键安装脚本在 scripts/install-curl-impersonate.sh：它会自动检测 CPU 架构（amd64/arm64）与 libc 类型（gnu/musl），下载对应版本并安装到/usr/local/bin，Docker 构建时也会调用它。

传输二：FlareSolverr —— 把 Cloudflare 质询交给专业解法

遇到完整的 Cloudflare "人机质询"页时，伪造指纹也没用——页面会执行 JavaScript 校验。FlareSolverr是一个专门跑真实无头浏览器来"过质询"的服务，degoog 把它做成了官方传输扩展。

在迁移文件 src/server/migrations/2026-05-canonical-ids-migration.ts 中可以看到它的规范 ID：degoog-org-official-extensions-flaresolverr-transport。

使用方式很直接：

1. 在设置页的扩展商店中安装 FlareSolverr 传输扩展（从 git 仓库拉取）；
2. 启动一个 FlareSolverr 服务容器，并在扩展设置中填写地址；
3. 把反爬严格的引擎的出站方式指向它。

质询页会被发送到 FlareSolverr，它用真实浏览器跑完后把"通行证"Cookie 带回来，degoog 再用这个 Cookie 继续正常请求。

传输三：真实 Firefox 浏览器会话 —— 终极保真度

如果某站点同时校验 TLS 指纹、JS 环境、鼠标轨迹……最稳妥的办法就是让一台真 Firefox 替你干活。

degoog 通过WebSocket与浏览器端扩展建立长连接，服务端把"打开页面、等待加载完成、读取内容"等指令通过消息队列发给浏览器执行。核心会话逻辑在 src/server/extensions/transports/ws-session.ts，支持：

• seqid序号配对请求与响应，默认 30 秒超时；
• dom_ready/dom_load_fail事件，精确等到页面 DOM 加载完成再取内容，避免抓到质询页半成品。

传输扩展只要实现wsHandler，注册器就会自动挂载 WebSocket 端点（见 src/server/extensions/transports/registry.ts 中的mountTransportWs调用），对应的端点注册在 src/server/extensions/transports/ws-registry.ts。相关测试覆盖在 tests/transports/ws-session.test.ts。

⚠️ 代价也很明显：需要一个常驻的浏览器实例，资源开销最大。建议只给最难的少数引擎使用。

传输四：curl-fallback —— 自动回退的"省心档"

日常使用最推荐的是自动档。它的逻辑只有几行，见 src/server/extensions/transports/builtins/auto/index.ts：

1. 先用最快的Bun 原生 fetch发请求；
2. 如果返回403 / 429 / 502 / 503（典型的反爬信号），立即用curl重试同一请求。

对新手来说，这一档覆盖了绝大多数场景，无需理解前面几种传输的细节。

选型建议：按场景选传输

几个实用提示：

• 🎯按引擎配置：不必全站统一，用outgoingTransport给每个引擎单独指定，把重武器留给最难的引擎；
• 🧪压测验证：仓库自带 scripts/stress-rate-limit.sh，可在更换传输后验证限流表现；
• 📦可扩展：注册器会从扩展目录加载第三方传输（src/server/extensions/transports/registry.ts），你甚至可以自己写一个。

写在最后

degoog 把"反爬对抗"做成了一套可插拔的传输层：轻量的 curl-impersonate 应对指纹识别，FlareSolverr 专克质询页，真实浏览器会话作为最终底牌，而自动回退档兜底日常使用。理解这 4 种传输的区别，你就能让自己的搜索引擎聚合器在面对各家反爬系统时游刃有余。

更多安装与配置细节，可参考 README.md 与 AGENTS.md。

【免费下载链接】degoogSearch engine aggregator with a comprehensive plugin/extension system项目地址: https://gitcode.com/gh_mirrors/de/degoog