企业官网建设流程全解析

搞浏览器这件事，我在不同项目里前后搭过四五次以太坊区块链浏览器，第一次折腾了整整两周，最后一次一个下午就跑通了全链路。差别全在几个关键分岔口选得对不对：执行层用什么客户端、历史状态要不要留全、索引服务跟节点是不是放在同一台物理机上。这篇文章就把这些路口一个个摊开，包括每一步为什么要这么选、参数怎么算出来、跑起来之后会卡在什么地方。以太坊区块链浏览器听上去像个庞然大物，本质上是一条数据管道加一个查询界面：底层全节点提供 JSON-RPC 接口，中间索引器把区块、交易、地址、代币、合约事件一条条抓下来落库，上层 Web 服务把这些结构化数据渲染成页面。这套东西适合正在做链上数据平台、私有链或测试链运维、又或者单纯想搞清楚区块浏览器里那些数字到底从哪来的朋友。有 Docker 基础就能跟着走，完全没碰过区块链节点的也能看懂每一步在干什么。

1. 架构先想清楚：三条路线与它们的成本边界

动手开机之前，我建议先花半小时把路线定下来。这一步定错，后面所有的调优都是白费。我看到过太多人上来就docker-compose up，跑了三天发现内部交易全是空的、代币余额查不出来，回头重来一遍索引，一周时间就没了。

1.1 自建、托管与"只做查询层"的三条路

第一条是完全自建：自己跑执行层节点和共识层节点，自己跑索引器，自己维护数据库。优点是数据完全自主，可以任意定制字段、加自己的业务表、把链上数据和线下数据关联起来；缺点是硬件和运维成本不低，主网全量索引动辄几百 GB 到数 TB 的数据库，磁盘 IO 是硬门槛。适合对数据有强诉求、需要二次开发的场景，比如做链上风控、做地址画像、做审计留痕。

第二条是只做查询层：节点直接用现成的第三方 RPC 服务，索引器指向远端接口，本地只有数据库和 Web 服务。这条路的门槛低很多，一台 8 核 32G 的机器就能跑起来，但会撞上两个硬限制。一是远端 RPC 通常对请求频率、单次返回条数、并发连接数都有配额，索引器回填历史数据的时候会把配额瞬间打爆；二是很多方法（尤其是debug_trace*和trace_*这类追踪类接口）在免费额度里根本不开放，而恰恰是这些接口决定了浏览器能不能显示出内部转账。所以这条路我只推荐给测试链、私有链或者做演示原型的场景。

第三条是混合路线：本地跑节点只负责提供 RPC，索引器和数据库放另一台机器，前端再加一层 CDN。这是我自己项目里最常用的形态，节点机器吃 IO 和带宽，应用机器吃 CPU 和内存，两类资源错峰，互不干扰。下面所有配置我都按这条路线写，另外两条把对应部分砍掉即可。

1.2 组件拆解：一条数据的完整旅程

先搞清楚一次"用户在浏览器里点开某个地址"背后发生了什么，后面的配置才知道每一项在管什么。

1. 执行层节点：维护账户状态、区块、交易、收据，对外提供eth_*、debug_*、trace_*等 RPC 方法。它是唯一的数据源头。
2. 共识层节点：合并之后，执行层必须挂一个共识层客户端才能确认链头。两者通过 Engine API 通信，端口默认 8551，用 JWT 做认证。没有共识层的执行层只能同步到合并前的高度，这一点新手最容易忽略。
3. 索引器（Indexer）：周期性地向节点拉取新区块，解析出交易、日志、内部调用，写入关系型数据库。它还要做反查表的构建，比如"某地址的所有交易""某代币的所有转账"，这些不是链上原生就有的索引，得靠索引器自己算。
4. 关系型数据库：存所有结构化结果。它是整个系统里最吃磁盘和内存的组件，也是索引速度的真正瓶颈所在。
5. Web 服务：读数据库、渲染页面、提供对外 API。它是只读的，可以横向扩多个实例。
6. 反向代理：负责 TLS 终止、静态资源缓存、限流。

一条交易的完整生命周期是：节点产块 → 索引器轮询到新块 → 解析交易和收据 → 写入transactions、logs、addresses等表 → 更新地址余额与计数器 → Web 服务从库里查出来给用户看。理解了这条链路，你就明白为什么"节点同步完了但浏览器页面还是空的"——那是索引器还没跑，或者索引器跑失败了。

2. 硬件盘算：先把账算明白再动手

我见过最典型的翻车是：拿一台 4 核 8G 的云主机，配了块普通云盘，然后问我为什么同步一个月还没好。以太坊主网节点的资源需求和一台普通 Web 服务器完全是两个量级，这里必须提前算清楚。

2.1 磁盘、内存、带宽的估算方法

磁盘是第一优先级，而且是唯一不能妥协的一项。执行层全节点（快照同步模式）的数据目录在 1TB 量级起步，并且随着链的增长每年都在往上走；如果选归档模式，那得按十 TB 量级去算。共识层数据相对小一些，几十到一百多 GB。再加上索引数据库，主网全量索引通常落在几百 GB 到数 TB 之间，具体取决于你启用了多少张表、保留多久的历史。

我的经验算法是这样的：节点数据目录 = 当前链数据量 × 1.5（给增长和临时文件留余量），数据库 = 节点数据目录 × 1.5 到 2（索引表带索引和冗余字段，膨胀比很高）。两块盘分开挂，别放同一个分区，否则数据库做 vacuum 的时候会把节点的 IO 全部抢走。

盘的类型必须是NVMe SSD。SATA SSD 勉强能跑，但同步和索引的时间会翻两三倍；机械盘直接放弃，随机读写完全跟不上，同步阶段会表现为"区块高度半天不动"。这一点我在早期用机械盘试过一次，同步速度大概是 NVMe 的十分之一，而且不断因为超时重连。

内存方面，执行层节点 16GB 起步，32GB 会舒服很多；共识层 8GB 够用；数据库单独一台的话 32GB 起步，shared_buffers能吃下大部分热数据之后，索引速度会有明显提升。如果全挤在一台机器上，我建议至少 64GB，否则 OOM Killer 会在半夜随机干掉你的某个进程。

带宽主要影响同步阶段。全量同步要下载的数据量在 1TB 以上，100Mbps 的下行大概能让你在几天内完成执行层同步；如果只有 10Mbps，那基本上是以周为单位。同步完成之后的日常运行带宽消耗很小，索引器和节点通常在同一个内网，走的是本地回环。

下面这张表是我自己在不同规模下的配置参考，按实际预算上下浮动即可：

2.2 全节点、归档节点、裁剪节点的分岔

这个选择直接决定了磁盘开销和浏览器的功能完整度，必须提前想清楚。

裁剪节点（pruned）：只保留最近一段时间的状态数据，历史状态会被逐步删掉。磁盘占用最小，同步最快，日常出块验证完全够用。但它有个致命短板——对历史区块做状态追踪会失败。也就是说，当用户点开一笔三年前的交易想看内部转账，节点会告诉你"状态不可用"。这是很多自建浏览器"只能看最近几个月"的根本原因。

归档节点（archive）：保留每一个区块高度的完整状态。任何历史区块的追踪都能成功，磁盘占用按十 TB 量级算，同步时间以周计。如果你要做的是面向全历史的公开浏览器，这是唯一正确的选择。

带历史的完整节点：这是中间态。以 Erigon 为代表的客户端，默认保留全部区块和收据的历史，同时对状态做了一定的裁剪策略，磁盘占用比归档小一个数量级，但对大多数历史区块的追踪依然可用。这是目前自建浏览器性价比最高的选择，也是我在生产环境里用得最多的一种。

提示：如果你选的是裁剪型客户端，一定要在配置里把内部交易抓取关掉，否则索引器会不停重试失败的历史区块，日志里刷满超时错误，还会拖慢新区块的索引速度。

3. 节点层落地：执行层与共识层一起跑

节点是整个系统的地基。地基没打好，上面所有配置都是浮沙。这一节我按"选型 → 启动 → 验证"的顺序写，命令可以直接抄。

3.1 客户端选型与对应的浏览器兼容性

执行层客户端有好几个成熟实现，对浏览器的友好程度差别很大，这是选型时最容易忽略的一点。

Geth 系：生态最广、文档最全、社区问题最好搜。缺点是默认裁剪状态，历史追踪能力弱；而且它不提供trace_block这类批量追踪方法，浏览器只能退而求其次用debug_traceTransaction逐笔追踪，速度慢，且对老区块会失败。适合做私有链、测试链，或者只关心近期数据的场景。

Erigon 系：磁盘占用小、同步快、保留完整历史，追踪类接口齐全。它是目前自建公开浏览器的主流选择。代价是对磁盘 IO 更敏感，数据库结构的维护动作多一些，初次同步的配置项也偏多。

Reth 系：新一代实现，同步速度非常快，接口兼容性好，但要选对模式——full模式仍然会裁剪历史状态，想做全历史追踪得开归档。

我的建议很直接：要做公开的全历史浏览器，选 Erigon 或 Reth 的归档模式；只做内部工具或测试链，Geth 足够。选型定下来之后，浏览器的ETHEREUM_JSONRPC_VARIANT参数要跟它对应，填错了会导致内部交易解析逻辑走错分支，症状是"交易详情页永远显示 0 条内部转账"。

3.2 JWT 认证与 RPC 暴露的安全边界

合并之后，执行层和共识层之间靠 Engine API 通信，必须共享一个 JWT 密钥文件。生成方式很简单：

openssl rand -hex 32 > /data/jwt.hex chmod 600 /data/jwt.hex

这个文件两个客户端都要指向它。执行层的启动参数大致如下（以 Geth 为例）：

geth \ --datadir /data/geth \ --syncmode=snapshot \ --http \ --http.addr 127.0.0.1 \ --http.port 8545 \ --http.api eth,net,web3,debug,trace \ --http.vhosts localhost \ --authrpc.addr 127.0.0.1 \ --authrpc.port 8551 \ --authrpc.jwtsecret /data/jwt.hex \ --maxpeers 100 \ --cache 8192

几个参数值得单独说。--http.addr一定要绑127.0.0.1，绝不能绑0.0.0.0——一旦把带debug命名空间的 RPC 暴露到公网，等于把整个节点的执行权限送出去了，任何人都能通过追踪接口把你的机器 CPU 打满。--http.api里debug和trace是内部交易解析必需的，但同时也是最耗资源的方法，所以只能在回环地址上开，让索引器从本地访问。--cache 8192是按机器内存给的，一般来说给到物理内存的四分之一到三分之一比较合适，这里假设是 32GB 的机器。

共识层这边（以 Lighthouse 为例）：

lighthouse bn \ --network mainnet \ --datadir /data/lighthouse \ --execution-endpoint http://127.0.0.1:8551 \ --execution-jwt /data/jwt.hex \ --checkpoint-sync-url <社区提供的检查点同步地址> \ --http \ --http-address 127.0.0.1 \ --http-port 5052 \ --metrics --metrics-address 127.0.0.1

--checkpoint-sync-url是个提速神器。共识层如果从创世开始同步，要验证历史上每一个 epoch 的签名，慢得让人怀疑人生；用检查点同步可以从一个较新的信任点开始，只回溯很短一段，把共识层的同步时间从几天压到几十分钟。这是我最推荐的一个开关，没有之一。

3.3 同步观测与卡点处理

同步过程中要盯三个地方：执行层的区块高度、共识层的同步状态、以及两个客户端之间的连接是否正常。

执行层的高度可以这样看：

curl -s -X POST -H 'Content-Type: application/json' \ --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \ http://127.0.0.1:8545

返回false表示同步完成；返回一个对象就说明还在追，里面的currentBlock和highestBlock相减就是还差多少。注意：这个差值不是线性的，刚开始可能差几百万块，但因为同步是按段并行拉的，后期会突然收窄，不要被一开始的数字吓到。

常见的卡点有这么几类。高度长时间不动，八成是 P2P 连不上对等节点，检查--maxpeers和防火墙的 TCP/UDP 端口是否放通。高度在涨但共识层报 engine API 错误，多半是 JWT 文件两边不一致，或者端口写错。同步到某个高度突然反复回滚，通常是磁盘空间不足或者 IO 超时，看节点日志里的write error关键字。

还有一个隐蔽的坑：节点同步期间，索引器如果已经在跑，会对着不断变动的链头疯狂重试，两边抢 IO。我的做法是节点同步完成度到 99% 以上再启动索引器，不要一边同步一边索引，那样只会让两边都变慢。

4. 索引与数据层：把链条数据变成可查的表

节点跑通之后，重头戏才刚开始。这一层是整个浏览器里最耗时、最容易出问题、也最能体现经验差距的部分。

4.1 PostgreSQL 参数调优清单

数据库是索引速度的真正瓶颈。默认配置的 PostgreSQL 是给一台小机器准备的，直接拿来索引主网会慢到让你怀疑硬件坏了。下面是 64GB 内存、NVMe 磁盘的机器上我自己在用的参数：

random_page_cost这一项很多人会漏。它是优化器估算随机读代价的参数，默认值假设磁盘有寻道时间，所以你写一个带索引的查询，优化器可能觉得"全表扫描更划算"，然后真的去扫几千万行。改成 1.1 之后，执行计划会重新倾向于走索引，页面响应时间能差出好几倍。

synchronous_commit关掉确实能显著提升写入吞吐，因为它不用等 WAL 落盘就返回。但这意味着机器突然断电可能丢最后几秒的数据，对索引来说可以接受（重跑就行），对生产环境不能接受。我的习惯是：首次回填期间关掉，回填完成后立刻改回on并重启数据库，不要图省事一直留着。

4.2 环境变量逐项拆解

索引服务本身是配置驱动的，环境变量填错一项，行为就会偏。下面这些是最关键的一批：

DATABASE_URL=postgresql://explorer:******@127.0.0.1:5432/explorer ETHEREUM_JSONRPC_VARIANT=erigon ETHEREUM_JSONRPC_HTTP_URL=http://127.0.0.1:8545 ETHEREUM_JSONRPC_TRACE_URL=http://127.0.0.1:8545 ETHEREUM_JSONRPC_WS_URL=ws://127.0.0.1:8546 CHAIN_ID=1 COIN=ETH SECRET_KEY_BASE=<用随机生成器产出的一长串> PORT=4000 INDEXER_DISABLE_INTERNAL_TRANSACTIONS_FETCHER=false

ETHEREUM_JSONRPC_VARIANT必须和你的节点实现匹配，这个前面说过，填错的症状是内部交易和部分合约解析异常。ETHEREUM_JSONRPC_TRACE_URL单独拎出来是有原因的——追踪类请求很重，如果和普通查询走同一个入口，容易把普通查询也堵住，分开配置的话可以把两者指到不同的节点实例上。SECRET_KEY_BASE是 Web 服务的会话签名密钥，必须是一段足够长的随机串，绝对不要用示例配置里那串默认值，否则任何人都能伪造会话。

还有个容易被忽略的：代币元数据的获取需要外部网络访问。索引器解析到 ERC-20 合约之后，会尝试调用合约的name、symbol、decimals方法，有些实现还会去拉取链外的图片资源。如果机器完全隔离外网，代币列表里会全是"未知代币"，看起来像 bug，其实是网络策略挡住的。

4.3 索引器与 Web 进程分离部署

同一个镜像可以跑两种角色，靠开关区分：

# 索引器进程：负责写库 docker run --env-file ./explorer.env \ -e DISABLE_INDEXER=false \ -e DISABLE_WEB=false \ blockscout/blockscout:latest # 只读 Web 进程：负责查询渲染 docker run --env-file ./explorer.env \ -e DISABLE_INDEXER=true \ blockscout/blockscout:latest

分开部署的好处很实在：索引器吃掉大量 CPU 和数据库连接的时候，Web 服务不会跟着卡死。我自己遇到过好几次索引回填期间页面完全打不开的情况，拆开之后这个问题就消失了。Web 进程可以开多个实例挂到反向代理后面，索引器只能有一个，多开会造成重复写入和唯一键冲突。

数据库初始化这一步不要跳过，首次启动前必须先跑迁移：

docker run --rm --env-file ./explorer.env \ blockscout/blockscout:latest \ ./bin/blockscout eval "Elixir.Explorer.ReleaseTasks.create_and_migrate()"

版本升级之后也要重新跑一次这条命令，否则新版本代码访问旧表结构，会报一堆"字段不存在"。

4.4 首次索引的时间预期与加速手段

主网从创世块开始索引，是个以天甚至以周计的过程。我在 16 核 64G + NVMe 的机器上，配合 Erigon 节点，全量索引大概要两到三周；如果只索引最近一年的数据，能压缩到几天。这个数字跟节点追踪接口的响应速度强相关，因为每一笔交易都要额外发一次追踪请求解析内部调用。

想把时间压下来，有几个实招。第一，把索引的起始块设成一个较新的高度，如果业务上不需要远古数据，直接从最近一年开始，能省掉七八成的时间。第二，分批回填，先把区块和交易这两张核心表灌满，让页面能用起来，代币、内部交易、合约验证这些次要模块后台慢慢补。第三，临时关掉一些非必要模块，比如代币持有者统计、合约源码验证这类计算量大的任务，等主流程跑完再打开。第四，监控数据库的写入延迟，如果pg_stat_activity里大量会话卡在IO等待，说明磁盘到瓶颈了，这时候加 CPU 没用，得换盘或者把 WAL 单独放到另一块盘上。

注意：索引过程中千万不要重启节点。节点重启会短暂不可用，索引器拿不到数据会标记失败并进入重试队列，有些任务的重试间隔是分钟级的，一重启可能造成十几分钟的空转。

5. 访问层：反向代理、HTTPS 与缓存

到这一步，浏览器已经在127.0.0.1:4000上跑起来了，接下来要把它安全地暴露出去。这一层配置不难，但配错了会直接影响可用性。

5.1 Nginx 关键配置

反向代理这块，最常出问题的是超时和请求体大小。区块浏览器的某些页面（尤其是带大量日志的交易详情页）响应时间可能超过默认的 60 秒，请求体也可能比较大，默认配置会直接返回 504 或 413。

server { listen 443 ssl http2; server_name browser.example.com; ssl_certificate /etc/ssl/fullchain.pem; ssl_certificate_key /etc/ssl/privkey.pem; client_max_body_size 20m; location / { proxy_pass http://127.0.0.1:4000; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 30s; proxy_send_timeout 120s; proxy_read_timeout 120s; } location ~* \.(js|css|png|svg|woff2)$ { proxy_pass http://127.0.0.1:4000; expires 30d; add_header Cache-Control "public, immutable"; } } server { listen 80; server_name browser.example.com; return 301 https://$host$request_uri; }

proxy_read_timeout从默认 60 秒提到 120 秒，是我踩坑之后加的。有些复杂地址的详情页要聚合几十张表的数据，冷缓存下确实会跑到七八十秒。当然，如果经常触及这个上限，说明该优化数据库查询了，而不是继续加超时。

X-Forwarded-Proto这一行不能少。少了它，应用会以为自己跑在 HTTP 下，生成的静态资源链接会是http://开头，浏览器在 HTTPS 页面里加载 HTTP 资源会被拦截，页面样式全崩。这个症状我第一次遇到时排查了很久，因为日志里一切正常。

5.2 静态资源与限流

静态资源加长缓存是必做的，前端打包出来的文件名带哈希，可以放心设immutable。真正需要小心的是 API 路径——如果对外开放了查询接口，一定要在代理层做限流，否则很容易被人写脚本把数据库拖垮。

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s; location /api { limit_req zone=api burst=20 nodelay; proxy_pass http://127.0.0.1:4000; # 其余代理头同上一段 }

10r/s 这个值对正常用户完全够用（一个页面最多也就几十个请求，分散在几秒内），对爬虫脚本则是明显的拦截。burst=20允许短时突发，避免用户同时打开多个标签页被误伤。

6. 长跑阶段：监控、备份与升级

浏览器搭起来只是开始，真正花时间的是后面几个月的维护。这一节讲的东西不性感，但能省掉你半夜被叫起来的次数。

6.1 必看的几个指标

监控不用做得很复杂，抓几个关键指标就够用。节点高度与链头高度的差值，超过几十个块就说明同步落后了，得查网络或者磁盘。索引器的最后处理区块高度，它应该紧跟着节点高度，如果差得越来越远，说明索引速度跟不上出块速度，长期下去会越拖越久。数据库连接数，接近max_connections的时候新请求就会开始排队。磁盘剩余空间，这个最要命，节点数据目录写满会导致客户端直接崩溃，而且恢复起来很麻烦。追踪接口的失败率，如果突然升高，通常意味着节点在裁剪历史状态，或者某个版本的兼容性出了问题。

我用一个很土但有效的办法：写个定时脚本，每五分钟把这些数字打到日志里，再用日志系统做阈值告警。不需要什么高大上的方案，能第一时间发现问题就行。

6.2 升级与数据库迁移顺序

节点客户端的升级要谨慎。执行层和共识层的版本要匹配，尤其是 Engine API 有变更的版本，先升共识层再升执行层，或者反过来，得看具体版本的发布说明。我的固定流程是：先在测试环境跑一遍，确认能正常同步、索引器能正常取数，再动生产。生产环境升级前一定先停索引器，节点升完并且追平链头之后再启动索引器，避免中间过程中的数据不一致。

浏览器本身的升级，顺序是固定的：先停索引器 → 跑数据库迁移 → 启动 Web 服务 → 启动索引器。跳过迁移直接启动，症状是一堆字段相关的报错；先启索引器再迁移，可能写进去半截脏数据。这两条我都经历过，代价是重新回填了几天。

数据库备份不用每天都做全量，增量加定期全量就够。真出问题的时候，重跑索引比恢复备份还快——前提是你知道从哪个高度开始重跑。所以我习惯在配置里把"索引起始块"做成可调项，出问题时把起点挪到最近一周，几小时就能追平。

7. 常见问题速查与避坑实录

7.1 问题速查表

7.2 三个我真正踩过的坑

第一个坑：以为节点同步完就万事大吉。早期我只看eth_syncing返回false就以为可以了，结果索引器取到的区块数据里收据字段是空的，原因是节点还没完成收据的回填（快照同步是分阶段进行的）。正确做法是看节点日志里有没有明确的"同步完成"标记，或者用eth_getBlockReceipts抽查几个近期区块，确认收据能正常返回。

第二个坑：把 Web 服务和索引器塞进同一个容器。一开始图省事只跑一个进程，结果索引回填期间页面完全打不开，用户体验极差。拆成两个容器之后，哪怕索引器在满负荷跑，Web 服务依然能正常响应。资源上多花的那点内存，换来的是可用性，非常值。

第三个坑：数据库没做定期维护。索引跑了几周之后，某些查询突然从几百毫秒涨到十几秒。查下来是表膨胀严重，死元组占比很高，autovacuum 的默认阈值对这种高频写入的表根本不够用。后来给几张核心表单独设了更激进的 autovacuum 参数，并且每周跑一次ANALYZE，查询计划才恢复正常。

我个人在实际操作中的体会是，这套系统里真正难的不是把服务跑起来——现在容器化之后，命令抄一抄半小时就能起——而是提前把数据量和时间成本算清楚。磁盘够不够、索引要跑多久、哪些功能可以先用简化版顶上，这三个问题想明白了，后面就是按部就班地填配置。反过来，如果一开始就抱着"先跑起来再说"的心态，大概率会在索引跑到一半的时候发现盘满了，然后从头再来一遍。