企业官网建设流程全解析

• 网络安全
• 网络
• 开发工具

本文是 curl-impersonate 的官方安装文档（INSTALL.md）的深度实战版。curl-impersonate 是一套对 curl 进行深度改造的特殊构建产物，能够让 TLS 与 HTTP/2 握手与真实浏览器（Chrome、Edge、Safari、Firefox）完全一致。本文系统讲解其三种构建路径——autotools 原生构建（Ubuntu / Red Hat 系 / macOS）、aarch64 交叉编译以及Docker 容器构建，并深入到 Makefile.in、configure.ac、Dockerfile 等源码层，说明每个依赖（NSS、BoringSSL、nghttp2、brotli）、每个 configure 参数的真实作用与底层传递链路。读完本文，你将能够在自己的机器上从零编译出两个版本（chrome 版 / firefox 版）的 curl-impersonate，并把它们安装到自定义路径，或直接产出一套可移植的 Docker 镜像。

一、版本与构建选项总览

INSTALL.md 开篇即点明了本项目的构建哲学：构建过程会自动完成"下载依赖 → 打补丁 → 编译依赖 → 编译打过补丁的 curl"这一整条流水线，用户无需手动逐个子项目去配置。当前仓库一共提供三种构建方式，按使用场景区分：

两个版本：chrome 版与 firefox 版

由于技术原因，curl-impersonate存在两个二进制版本，这一点在 INSTALL.md 中被反复强调：

• chrome 版：用于伪装 Chrome、Edge 与 Safari。它基于 BoringSSL（Google 的 TLS 库）编译，相关构建入口集中在 chrome/ 目录。
• firefox 版：用于伪装 Firefox。它基于 NSS（Mozilla 的 TLS 库，即 Firefox 使用的库）编译，相关构建入口集中在 firefox/ 目录。

这一区分的根源在于两个浏览器家族使用完全不同的 TLS 库与扩展行为，从 README.md 的 "How?" 一节可以看到，正是"用 NSS/BoringSSL 替换 OpenSSL、修改 TLS 扩展与 SSL 选项配置、增加新 TLS 扩展、改写 HTTP/2 设置、配合--ciphers/--curves/-H等非默认 flags"这五类改动，才让最终产物的网络侧观感与真实浏览器无异。

二、Native Build：Ubuntu 从零构建

2.1 安装构建依赖

sudo apt install build-essential pkg-config cmake ninja-build curl autoconf automake libtool # For the Firefox version only sudo apt install python3-pip libnss3 pip install gyp-next export PATH="$PATH:~/.local/bin" # Add gyp to PATH # For the Chrome version only sudo apt install golang-go unzip

这些依赖的用途可以在 Makefile.in 的构建规则中找到一一对应：

• cmake+ninja：BoringSSL 采用 CMake + Ninja 构建（见 Makefile.in 中@cmake@ ... -GNinja ..与@ninja@）。configure 脚本会依次探测cmake3/cmake与ninja/ninja-build两种命名，见 configure.ac。
• autoconf automake libtool：curl 与 nghttp2 被打补丁后需要重新生成 configure 脚本（autoreconf -fi，见 Makefile.in 与 Makefile.in）。
• golang-go：BoringSSL 的构建依赖 Go（其构建系统使用 Go 生成代码）。
• unzip：解压 BoringSSL 的 zip 源码包（Makefile.in）。
• python3-pip+gyp-next：NSS 使用 gyp 构建系统生成项目文件，firefox 版必须安装。
• libnss3：为 firefox 版运行时提供libnssckbi.so（内含 Mozilla 根证书库），详见后文"Firefox 版本注意事项"。

2.2 克隆、配置与编译安装

git clone https://github.com/lwthiker/curl-impersonate.git cd curl-impersonate mkdir build && cd build ../configure # Build and install the Firefox version make firefox-build sudo make firefox-install # Build and install the Chrome version make chrome-build sudo make chrome-install # You may need to update the linker's cache to find libcurl-impersonate sudo ldconfig # Optionally remove all the build files cd ../ && rm -Rf build

值得注意的几点：

• 建议在独立的build/目录中运行../configure，这样源码目录保持干净，便于之后清理。
• make firefox-build与make chrome-build是两个完全独立的构建目标，它们的产物同名但互斥（curl 源码目录中的.firefox与.chrome标记文件会互相清除，见 Makefile.in 与 Makefile.in），因此同一份源码可以先后构建出两个版本。
• make firefox-install会把firefox/curl_ff*系列包装脚本装进@bindir@；make chrome-install则安装chrome/curl_chrome*、chrome/curl_edge*、chrome/curl_safari*三套脚本（见 Makefile.in 与 Makefile.in）。
• 安装完成后运行sudo ldconfig，确保动态链接器能找到libcurl-impersonate。

2.3 安装路径与验证

默认安装前缀为/usr/local，产物包括curl-impersonate二进制、libcurl-impersonate库以及全套包装脚本。如需自定义安装位置：

../configure --prefix=/path/to/install/

安装完成后可以用两种方式运行：

# 方式一：包装脚本（推荐，自动带上全部伪装参数） curl_ff98 https://www.wikipedia.org curl_chrome99 https://www.wikipedia.org # 方式二：直接调用二进制并自行控制参数 curl-impersonate-ff https://www.wikipedia.org curl-impersonate-chrome https://www.wikipedia.org

注意：方式二直接运行二进制时，默认不会产生与浏览器一致的 TLS/HTTP2 签名，因为伪装所需的--ciphers、-H等参数是由包装脚本附加的（详见 docs/02_USAGE.md）。包装脚本的真实内容可以参考 chrome/curl_chrome99 与 firefox/curl_ff98，例如 chrome 版会追加--tlsv1.2 --alps --cert-compression brotli --http2 --compressed及一整套-H请求头。

此外，Makefile 还提供了构建自检目标，可在安装前验证关键特性是否全部编译进二进制（仅在本机非交叉编译时执行）：

make chrome-checkbuild # 检查 zlib / brotli / nghttp2 / BoringSSL make firefox-checkbuild # 检查 zlib / brotli / nghttp2 / NSS

其实现见 Makefile.in 与 Makefile.in：本质上是对./src/curl-impersonate-ff -V与./src/curl-impersonate-chrome -V的输出做grep断言。在交叉编译时会跳过该检查并打印 "Cross compiling, skipping checkbuild"。

三、Native Build：Red Hat 系（CentOS / Fedora / Amazon Linux）

Red Hat 系与 Ubuntu 的主要差异在于依赖安装命令与包名：

yum groupinstall "Development Tools" yum groupinstall "C Development Tools and Libraries" # Fedora only yum install cmake3 python3 python3-pip # Install Ninja. This may depend on your system. yum install ninja-build # OR pip3 install ninja

firefox 版额外依赖：

yum install nss nss-pem pip3 install gyp-next

chrome 版需要 Go；若系统没有打包 golang，请参考 Go 官方安装文档：

yum install golang

依赖就绪后，后续的mkdir build && cd build && ../configure && make chrome-build等步骤与 Ubuntu 完全一致（INSTALL.md 明确指引 "Then follow the 'Ubuntu' instructions for the actual build"）。

这里补充一个从源码确认的细节：configure.ac在探测构建工具时同时接受cmake3 cmake与ninja ninja-build两种候选名（configure.ac），这正是为兼容 Red Hat 系（cmake3、ninja-build）与 Debian 系（cmake、ninja）不同包命名而设计的。

四、Native Build：macOS

macOS 侧使用 Homebrew 安装依赖，且由于 macOS 默认没有 GNU make，编译安装命令需用gmake：

brew install pkg-config make cmake ninja autoconf automake libtool # For the Firefox version only brew install sqlite nss pip3 install gyp-next # For the Chrome version only brew install go git clone https://github.com/lwthiker/curl-impersonate.git cd curl-impersonate mkdir build && cd build ../configure # Build and install the Firefox version gmake firefox-build sudo gmake firefox-install # Build and install the Chrome version gmake chrome-build sudo gmake chrome-install # Optionally remove all the build files cd ../ && rm -Rf build

macOS 特有细节：在 Makefile.in 中，NSS 构建完成后会显式rm -Rf $(nss_install_dir)/lib/*.dylib，删除动态库以强制链接器在链接 curl 时使用静态库——这是 macOS 上构建 firefox 版能成功的关键 hack。另外 Makefile 会将 autoconf 风格的系统名转换为 CMake 风格（darwin*→Darwin，见 Makefile.in），保证 brotli 与 BoringSSL 的 CMake 构建在 macOS 上正常工作。

五、静态编译与 curl 构建定制

5.1 静态编译

如果希望curl-impersonate与libcurl-impersonate静态链接（产物可独立拷贝到其它机器运行）：

../configure --enable-static

该开关在 configure.ac 中定义，默认值为no；置为yes后，Makefile.in 会向 curl 的 configure 追加--enable-static --disable-shared，从而只产出静态二进制。

5.2 定制 curl 自身构建

底层 curl 的 configure 参数可以通过CURL_CONFIG_FLAGS环境变量透传：

../configure CURL_CONFIG_FLAGS="--disable-rtsp"

该变量的传递链路非常清晰：先在 configure.ac 中通过AC_ARG_VAR声明为可配置变量，随后在 Makefile.in 中代入CURL_CONFIG_FLAGS，最终拼接进 curl 的 configure 命令（firefox 版见 Makefile.in，chrome 版见 Makefile.in）。除了用户传入的 flags，Makefile 还会自动追加：

• firefox 版：--with-nghttp2=<dir>、--with-brotli=<dir>、--with-nss=<dir> --with-nss-deprecated、--enable-websockets、USE_CURL_SSLKEYLOGFILE=true，并用CFLAGS补充 NSS/nspr 头文件路径（Makefile.in）。
• chrome 版：--with-nghttp2=<dir>、--with-brotli=<dir>、--with-openssl=<boringssl 构建目录>、--enable-websockets、USE_CURL_SSLKEYLOGFILE=true，并追加LIBS="-pthread"（Makefile.in）。

其中USE_CURL_SSLKEYLOGFILE=true是为了开启 SSLKEYLOGFILE 调试能力（Dockerfile 注释也明确写着 "Enable keylogfile for debugging of TLS traffic"），便于用 Wireshark 分析 TLS 流量。

六、Firefox 版本注意事项：NSS 与根证书

firefox 版将 NSS（Firefox 的 TLS 库）静态编译进 curl，但 NSS 要验证服务器证书，还需要一份可信根证书列表。curl 在运行时动态加载 NSS 库中的libnssckbi（内含 Mozilla 根证书库）。如果缺少它，会出现以下两类经典报错：

curl: (60) Peer's Certificate issuer is not recognized

或

curl: (77) Problem with the SSL CA cert (path? access rights?)

排查步骤：

1. 确认 NSS 已按前文安装（Ubuntu：sudo apt install libnss3；Red Hat：yum install nss nss-pem；macOS：brew install nss）。
2. 若问题依旧，可能是 NSS 被安装到了非标准路径（例如/usr/lib之外），此时可借助交叉编译章节的--with-libnssckbi参数显式指定libnssckbi.so的所在目录。

这一机制在 firefox/Dockerfile 中也有明确注释：curl 会尝试从/usr/lib/x86_64-linux-gnu/nss/libnssckbi.so加载证书，该文件由 Debian/Ubuntu 的libnss3包提供；最终镜像层又追加了nss-plugin-pem（firefox/Dockerfile）。临时规避方案是curl -k关闭证书校验，但这会破坏安全验证，仅在调试时使用。

七、Cross Compiling：为 aarch64（ARM64）交叉编译

INSTALL.md 明确指出：仓库对交叉编译提供了基础支持，目前主要用于从 x86-64 主机构建 aarch64 版本。交叉编译比原生构建更棘手，有两个主要原因：

1. zlib 必须为目标架构单独编译，否则链接失败；
2. 一些路径必须手动指定，因为 curl 自身的构建系统在交叉环境下无法自动探测。

官方示例（Ubuntu x86_64 → aarch64）：

sudo apt-get install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu ./configure --host=aarch64-linux-gnu \ --with-zlib=/path/to/compiled/zlib \ --with-ca-path=/etc/ssl/certs \ --with-ca-bundle=/etc/ssl/certs/ca-certificates.crt \ --with-libnssckbi=/usr/lib/aarch64-linux-gnu/nss make chrome-build make firefox-build

各参数含义：

• --with-zlib=PATH：指向为目标架构编译好的 zlib 库所在目录。该参数在 configure.ac 中定义，支持三种取值形态：不传/传--with-zlib（自动检测系统 zlib）、传--with-zlib=PATH（使用指定路径）、传--without-zlib（不支持，直接AC_MSG_ERROR报错）。Makefile 会原样传递给 curl 的--with-zlib（Makefile.in）。
• --with-ca-path=DIRECTORY与--with-ca-bundle=FILE：原样传递给 curl 的 configure，用于告诉 curl 在目标系统上到哪里找 CA 证书（configure.ac）。二者"仅对 chrome 版生效"（对应 Makefile.in 中只有 chrome 配置块会拼接这两个参数；firefox 版用 NSS 的证书库，不走这条路径）。
• --with-libnssckbi=DIRECTORY：指定目标系统上libnssckbi.so所在目录。只有当 NSS 未安装在标准位置（如/usr/lib）时才必须提供（configure.ac）。该参数会被 Makefile 传给 curl 的--with-libnssckbi（一个为本项目新增的 configure 选项，见 Makefile.in）。

交叉编译在 Makefile 层面的特殊处理还包括：NSS 的构建脚本本身不支持交叉编译，因此 Makefile 会先手动交叉编译 NSPR（NSS 的底层依赖），再以--with-nspr指向该产物去构建 NSS（Makefile.in）；同时根据host_cpu是否 64 位自动决定use_64与--enable-64bit配置。nghttp2 与 curl 的 configure 都会继承--host=$(host_alias)（Makefile.in）。

八、Docker Build：可复现的参考实现

INSTALL.md 将 Docker 构建定位为"更可复现、且作为参考实现"。两个 Dockerfile 均由 Dockerfile.template 通过 generate_dockerfiles.sh（基于 mustache 模板渲染）生成，包含 Debian 与 Alpine 两个变体。

8.1 Chrome 版本镜像

docker build -t curl-impersonate-chrome chrome/

构建产物位于镜像的/usr/local目录：

• curl-impersonate-chrome/curl-impersonate：可伪装 Chrome/Edge/Safari 的 curl 二进制。静态链接libcurl、BoringSSL 与 libnghttp2，避免与系统既有库冲突。官方说明标注其"在 Ubuntu 20.04 上测试可用"。既可在容器内直接使用，也可docker cp拷出，或作为多阶段构建（multi-stage build）的中间产物。
• curl_chrome99、curl_chrome100、…：携带全部所需 flags 的包装脚本。
• libcurl-impersonate-chrome.so/libcurl-impersonate.so：带伪装能力的 libcurl 动态库，供库方式集成。

8.2 Firefox 版本镜像

docker build -t curl-impersonate-ff firefox/

产物结构类似（curl-impersonate-ff静态链接 libcurl、nss、libnghttp2；curl_ff91esr、curl_ff95、… 包装脚本；libcurl-impersonate-ff.so）。特别提醒：即使在容器外使用，也建议安装libnss3——虽然 nss 已静态编译进二进制，但 curl 仍会动态加载包含 Mozilla 根证书库的libnssckbi.so：

sudo apt install libnss3

若不想安装，可退而使用curl -k关闭证书校验（不推荐用于生产）。

8.3 从 Dockerfile 看到的构建流水线

阅读 chrome/Dockerfile 可以还原出一条完整的构建流水线，这与 Makefile 的流程一一对应：

1. 以python:3.11-slim-bookworm为构建阶段基础镜像（Python 用于构建 libnss）；
2. 编译 brotli 1.0.9（cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=./installed）；
3. 下载指定 commit 的 BoringSSL，应用 chrome/patches/boringssl-old-ciphers.patch，用 CMake+Ninja 编译；
4. 编译 nghttp2 1.56.0（--with-pic --disable-shared，仅生成静态库）；
5. 下载 curl-8.1.1，应用 chrome/patches/curl-impersonate.patch（及其它补丁，如 chrome/patches/curl-CVE-2023-38545.patch），再autoreconf -fi重新生成 configure；
6. 先以--enable-static --disable-shared静态编译出curl-impersonate二进制，并用grep -q系列断言校验 zlib/brotli/nghttp2/BoringSSL/wss 特性齐全、ldd确认无动态依赖（chrome/Dockerfile）；
7. 再重新以动态方式编译出libcurl-impersonate-chrome.so及其符号链接，同样校验；
8. 多阶段构建收尾：最终镜像debian:bookworm-slim只装入产物、CA 证书与包装脚本。

firefox 版在步骤 1-3 处的差异是：下载并静态构建 NSS 3.92（含 nspr 4.35，./build.sh -o --disable-tests --static --python=python3，见 firefox/Dockerfile），最终镜像额外安装libnss3 nss-plugin-pem（firefox/Dockerfile）。

此外，Alpine 变体（如 chrome/Dockerfile.alpine）会用apk安装依赖，并把包装脚本的 shebang 从/usr/bin/env bash改写为/usr/bin/env ash以适配 Alpine 的默认 shell（chrome/Dockerfile.alpine）；Docker Hub 上发布的基于 Alpine 与 Debian 的官方镜像可以直接docker pull/docker run使用（见 README.md）。

九、安装后的验证与配套测试

构建安装完成并非终点。仓库在 tests/ 目录提供了签名一致性测试，用于验证curl-impersonate的网络签名与目标浏览器一致（而非测试 curl 本身的功能），详见 tests/README.md：

# 先构建好两个 Docker 镜像，再构建并运行测试镜像 docker build -t curl-impersonate-tests tests/ docker run --rm curl-impersonate-tests

测试原理：对每个受支持的浏览器，测试会（1）抓包提取 Client Hello 与 tests/signatures 中记录的已知浏览器签名比对；（2）连接本地nghttpdHTTP/2 服务器，比对伪头（pseudo-headers）与普通头的顺序。已知缺口是尚未测试 HTTP/2 SETTINGS 帧的完全一致性。各浏览器版本与包装脚本的完整对照表记录在 browsers.json 与 README.md。

十、常见问题速查

十一、小结

从 INSTALL.md 出发，结合仓库源码可以确认 curl-impersonate 的构建体系是一个"全自动依赖流水线"：无论走 Makefile.in 驱动的主机构建/交叉编译，还是走 Dockerfile.template 渲染出的容器构建，核心都是"brotli + nghttp2 + 特定 TLS 库（NSS 或 BoringSSL）+ 打补丁后的 curl"，并在最后通过特性断言与签名测试来保证产物质量。对普通用户而言，最省事的方式是直接使用官方发布（GitHub Releases 的预编译二进制或 Docker Hub 镜像，详见 README.md）；需要定制路径、目标架构或深入调试签名时，本文的三种构建路径与底层参数说明可以直接作为操作手册使用。

• 网络安全
• 网络
• 开发工具