如何搭建以太坊节点（2026 指南）

以太坊节点可让您直接访问网络：拥有自己的 JSON-RPC endpoint，没有 rate limit，也没有第三方读取您的查询请求。本指南将带您从一台空白的 Ubuntu 服务器，一步步搭建出已同步的节点，全程提供可复制粘贴的命令——Geth 作为执行客户端，Lighthouse 作为共识客户端，二者均由 systemd 管理。本文还涵盖了大多数教程忽略的内容：2026 年的硬件配置、同步耗时、每月成本，以及何时改用 API 更划算。

什么是以太坊节点？

以太坊节点是一台运行以太坊客户端软件的计算机，它存储区块链的副本，依据协议规则校验每一个新进区块，并对外提供 JSON-RPC 接口，供 wallet 和应用程序读取链上数据、发送交易。

自 2022 年 9 月的 Merge 以来，“客户端” 实际上是必须并行运行的两个程序。执行客户端(Geth、Nethermind、Besu、Erigon 或 Reth)持有 state、执行交易并响应 JSON-RPC 调用。共识客户端(Lighthouse、Prysm、Teku、Nimbus 或 Lodestar)负责 proof of stake：它跟随 beacon chain，并告知执行客户端当前的区块头是哪一个。两者通过一个经过身份验证的本地端口(8551)通信，并使用共享的 JWT secret 相互验证身份。缺少任何一方,都不是一个正常工作的节点。这一细节让大多数初次操作者栽了跟头。

存储配置分为三种。Full node 保留近期 state 并对旧数据进行 pruning；截至 2026 年年中，Geth 大约需要 1.2–1.4 TB。Archive node 保留每一个历史 state——在 Geth 经典的基于哈希的存储布局下远超 10 TB，而在专为此设计的客户端(如 Erigon 和 Reth)上约为 2–3 TB。Light node 仅下载区块头，听起来很有吸引力，但在主网上几乎没有 peer 会为 light 客户端提供服务，因此这不是一条实际可行的接入路径。

以太坊节点的硬件要求

以下数字描述的是 2026 年的 full node 配置。Archive node 是另一个独立的项目，而 validator 不会在稳健的 full node 之上增加任何额外硬件需求。

其中两行值得详细说明。

存储必须是 NVMe。同步过程会以高速率写入大量小型随机数据块。SATA SSD 经常会在 Geth 的 state heal 阶段卡住数天，而使用默认 IOPS 的云盘往往根本无法完成同步。带 DRAM 缓存的 TLC NVMe 硬盘是稳妥的选择。关于容量：Geth 的数据库大约占用 1.2 TB，Lighthouse 再增加约 200–250 GB，因此 2 TB 目前够用,但余量不多——4 TB 能为您多撑几年。

流量同样不可忽视。一个节点每月大约会产生 1 TB 量级的流量。家庭宽带能轻松应对，但流量限额较紧的 VPS 套餐则不然。

Linux、macOS 和 Windows 均可运行。以下所有命令均假设使用 Ubuntu 24.04,这是常见的服务器默认系统。

运行节点的几种方式

您不必事事亲自动手搭建。即插即用的一体机(如 DappNode 和 Avado)是预先配置好、带有仪表盘的设备：购买、连接、按照向导操作即可。ARM 开发板同样可行——Ethereum on ARM 为配备 NVMe 存储的 Raspberry Pi 5 级别开发板发布了现成镜像，运行成本低,但同步速度较慢。启动器(launcher)能自动化手动搭建流程：eth-docker(基于 Docker，需要一定的终端知识)、Stereum(通过 SSH 在远程服务器上安装客户端,配有图形界面)、NiceNode(选择客户端，几次点击即可启动)以及 Sedge(Nethermind 出品的 CLI 向导，可生成 Docker 配置)。

云端还是本地？开发阶段用 VPS 就够了。如果抗审查性是您的动机之一，请在自有硬件上运行节点——位于大型云服务区域内的节点会继承该服务商所在司法辖区的法律及服务条款。

本指南接下来的部分将带您完成手动搭建。这种方式能让您学到最多，而您学到的一切都可以迁移应用到各类启动器上。

分步指南：在 Ubuntu 上搭建 Geth + Lighthouse

1. 准备服务器

sudo apt update && sudo apt upgrade -y
sudo useradd --no-create-home --shell /usr/sbin/nologin geth
sudo useradd --no-create-home --shell /usr/sbin/nologin lighthouse
sudo mkdir -p /var/lib/geth /var/lib/lighthouse
sudo chown geth:geth /var/lib/geth
sudo chown lighthouse:lighthouse /var/lib/lighthouse

只开放 peer-to-peer 所需端口，不开放其他任何端口：

sudo ufw allow 30303 comment 'geth p2p'
sudo ufw allow 9000 comment 'lighthouse p2p'
sudo ufw allow 9001/udp comment 'lighthouse quic'

端口 8545(JSON-RPC)和 8551(engine API)对外保持关闭；在下面的 unit 配置中，二者均绑定到 localhost。

2. 安装 Geth

sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt update
sudo apt install -y ethereum
geth version

3. 安装 Lighthouse

Lighthouse 以静态二进制文件的形式发布。以下脚本始终会获取最新版本：

LH=$(curl -s https://api.github.com/repos/sigp/lighthouse/releases/latest | grep -m1 '"tag_name"' | cut -d '"' -f 4)
curl -LO "https://github.com/sigp/lighthouse/releases/download/${LH}/lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
tar xzf "lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
sudo mv lighthouse /usr/local/bin/
lighthouse --version

验证下载内容：每个发布页面都列出了 SHA-256 校验和以及 PGP 签名；运行 sha256sum 进行比对，或导入 Sigma Prime 的密钥并使用 gpg --verify。被替换的二进制文件是真实存在的攻击向量，而这项检查只需要一分钟。

4. 创建 JWT secret

sudo mkdir -p /var/lib/jwt
openssl rand -hex 32 | sudo tee /var/lib/jwt/jwt.hex > /dev/null

两个客户端都会读取此文件。如果它们看到的 secret 不一致，就会拒绝彼此通信(参见故障排查部分)。

5. Geth 的 systemd unit

创建 /etc/systemd/system/geth.service：

[Unit]
Description=Geth execution client (mainnet)
After=network-online.target
Wants=network-online.target

[Service]
User=geth
Group=geth
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
ExecStart=/usr/bin/geth \
  --mainnet \
  --syncmode snap \
  --datadir /var/lib/geth \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3,txpool \
  --authrpc.addr 127.0.0.1 --authrpc.port 8551 \
  --authrpc.vhosts localhost \
  --authrpc.jwtsecret /var/lib/jwt/jwt.hex

[Install]
WantedBy=multi-user.target

TimeoutStopSec=600 很重要：Geth 在关闭时会将 state 刷写到磁盘，过早终止进程是导致数据库损坏的典型原因。

6. Lighthouse 的 systemd unit

创建 /etc/systemd/system/lighthouse.service：

[Unit]
Description=Lighthouse consensus client (mainnet)
After=network-online.target geth.service
Wants=network-online.target

[Service]
User=lighthouse
Group=lighthouse
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --execution-endpoint http://127.0.0.1:8551 \
  --execution-jwt /var/lib/jwt/jwt.hex \
  --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \
  --http

[Install]
WantedBy=multi-user.target

checkpoint sync 的 URL 让 Lighthouse 能够从近期的一个已最终确定的 state 开始，而不必从 genesis 重新回放整条 beacon chain：只需数秒，而非数天。您对这个起点端点给予了信任；如果这让您有所顾虑，可以将 state root 与 beaconstate.info 等第二个来源进行比对。

7. 启动并观察

sudo systemctl daemon-reload
sudo systemctl enable --now geth lighthouse
journalctl -fu geth

Geth 会先记录区块头下载日志，随后是连续不断的 “Imported new chain segment” 日志行；Lighthouse 会在几分钟内报告已同步的 slot。检查同步进度：

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

{"result":false} 表示已完全同步。同步过程中，您得到的将是一个进度对象。

同步需要多长时间？

以太坊没有官方数据库快照可供下载，也不需要——快速同步的路径已经内置在客户端中。

启用 checkpoint sync 的 Lighthouse 能在一分钟内追上链头，并在后台补齐历史区块。处于 snap sync 模式(默认模式)的 Geth 会从网络拉取约 800 GB 到 1 TB 的数据，然后在本地重建 state trie。在推荐配置的硬件上，预计需要一到两天；在最低配置且磁盘性能一般的情况下，则需要三到五天。最后阶段是 “state heal” 阶段，如果它运行数天仍未完成，说明您的磁盘速度太慢——参见故障排查部分。

初始同步完成后，情况会趋于平稳。自 1.13 版本起，Geth 会实时进行 state pruning(基于路径的 state 存储)，因此数据库不会再像老版本指南警告的那样无限增长。Geth 1.16 及更高版本还可以丢弃 Merge 之前的历史数据(--history.chain postmerge)，如果空间紧张，这能释放几百 GB。

同步模式：snap、full 与 archive

Geth unit 中的 --syncmode 标志决定了您自行验证链上多少内容，以及为此需要支付多少磁盘空间成本。共有三种模式，正确的选择取决于您希望节点回答的问题类型。

Snap sync 是默认模式，也是本指南所使用的模式。Geth 直接从 peer 下载当前 state，向前验证区块头直至 genesis，然后修复 state trie。结果是：一到两天内即可获得一个可服务的 full node，截至 2026 年年中数据库约为 1.2–1.4 TB，并会持续增长。

Full sync(--syncmode full)会重新执行自 2015 年以来的每一笔交易，而不是下载 state。磁盘上的最终结果与经过 pruning 的数据库相同,但即使在强劲的硬件上，同步也要耗费数周时间。选择它只有一个理由：您不愿意信任 state 下载,而希望在自己的机器上重新计算全部历史。这是一种研究立场，而非运维需求。

Archive 模式处于另一个维度：在 full sync 之上加上 --gcmode archive，会保留每一个中间 state 而不进行 pruning。只有 archive node 能回答 “在区块 15,000,000 时这个余额是多少” 这类问题，或者无需重新计算即可执行深度 trace，而索引器、税务工具和分析平台正需要这些能力。在 Geth 经典的基于哈希的存储布局下，这需要远超 10 TB 的空间。Erigon 和 Reth 采用不同方式存储历史数据，截至 2026 年年中,其 archive node 的规模处于 2–3 TB 区间，因此几乎所有新的 archive 部署都会从这两者之一开始；Geth 较新的基于路径的 archive 模式在同一体量级别中运行，但生产环境的实践经验较少。

对于支付类后端而言，snap sync 足以回答所有问题：当前余额、新区块、交易回执。Archive 则是为您需要重建过去数据的那一天而准备的。

客户端选择与多样性

Geth 加 Lighthouse 是一个稳健的默认选择,而它的流行度恰恰也是隐患所在。以太坊的安全模型假设没有任何一个客户端控制了网络中过大的份额：如果某个 consensus bug 出现在拥有超过三分之二验证者份额的客户端中，可能会最终确定一条错误的链——这是协议无法干净撤销的唯一一种故障。即便只有三分之一的份额也令人不安,因为仅仅这一个客户端的失效就足以阻断最终确定性。

截至 2026 年年中的网络格局：Geth 依然在执行层占据主导地位，各项测算显示其份额在三分之一到约 40% 之间；Nethermind 紧随其后，份额在百分之二十到三十之间；Besu 和 Reth 处于较低的两位数区间；Erigon 占据几个百分点。在共识层，按大多数统计口径,Lighthouse 已经超过了三分之一这一警戒线，Prysm 位居第二，其后是 Teku 和 Nimbus。每当有一位运营者选择了少数派客户端,整个网络就会变得更安全一分，而该运营者几乎没有任何损失——所有执行客户端都使用同一套 JSON-RPC，所有共识客户端都使用同一套 beacon API。

2025 年末让这个论点变得具体起来。在 Fusaka 升级后不久，一个被广泛使用的共识客户端中的 bug 迫使团队紧急发布补丁，而运行在其他客户端上的节点则不受影响地持续进行验证。使用少数派组合的运营者只是读到了这起事件的报道,而无需亲自处理它。

对于第一个节点而言，本指南采用的组合已经足够。对于第二个节点，或任何专业用途，请选择少数派组合，比如 Nethermind 搭配 Teku，或 Reth 搭配 Nimbus。上述搭建流程几乎可以一比一迁移——每种组合都需要相同的 JWT secret 和相同的 engine API 接线方式；只有二进制文件、参数标志和数据目录会有所不同。

运行以太坊节点的成本是多少

这里不提供具体价格，因为它们每月都在变化，且因国家而异。取而代之的是一套自行计算的方法。

自有硬件：满足硬件要求档位的迷你 PC(8 核、32 GB RAM、2–4 TB NVMe)是一笔一次性支出，价格处于几百欧元的中间区间。功耗大约为 30–60 W。计算方式：0.03–0.06 kW × 720 小时 ≈ 每月 20–45 kWh；再乘以您当地的电价。按 0.30 欧元/kWh 计算，这大约是每月 6–13 欧元，另加您本来就要支付的网络接入费用。

租用服务器：能提供真正 2 TB NVMe 的 VPS 套餐并不常见，因此实际上您通常会选用入门级独立服务器。这会让您的支出落在每月几百欧元的较低区间——这只是一个数量级的估算，而非报价单。配置了预置 IOPS 的云实例，价格会明显高于同等配置的独立服务器。

您的时间：借助本指南，初次搭建大约花费一个下午；此后是客户端更新和偶尔查看日志，按每月一小时计算即可。如果您要为自己的时间计价，这一项也应计入总成本。

监控与健康检查

三个问题涵盖了节点的健康状况：进程是否在运行、是否已同步、是否拥有 peer。systemd 可以用 systemctl is-active geth lighthouse 回答第一个问题。另外两个问题在两个层级上各有对应的 endpoint：

# execution: peer count as hex; eth_syncing from step 7 covers sync state
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

# consensus: HTTP 200 = synced, 206 = still syncing
curl -s -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1:5052/eth/v1/node/health

得益于 unit 中已经设置的 --http 标志，Lighthouse 的 REST API 监听在 5052 端口。/eth/v1/node/health endpoint 会将同步状态编码进 HTTP 状态码中，因此非常适合作为脚本和负载均衡器的探测目标；如果您想要具体数字，/eth/v1/node/syncing 会返回以 slot 计的差距。一个执行这些检查外加 df -h /var/lib/geth、并在出现异常时发送邮件的定时任务(cron job)，对个人节点而言就是一套完整的监控方案。

如需仪表盘，可为 Geth(Prometheus endpoint 位于 6060 端口)和 Lighthouse(5054 端口)都添加 --metrics 参数，将两者都保持在 localhost 上，并导入这两个项目各自发布的 Grafana 仪表盘。无论您构建什么，都请优先设置这两条告警：磁盘使用率超过 85%，以及区块高度十分钟无变化。这两条几乎能在用户察觉之前捕捉到几乎所有真实故障。

维护与升级

客户端更新并非可选项。硬分叉(hard fork)需要新版软件，运行旧版本的节点会在分叉区块处直接停止跟随链的进展。请订阅 Geth 和 Lighthouse 在 GitHub 上的发布动态，以及 Ethereum Foundation 的博客——目前该网络大约每年发布一次重大升级，期间穿插各客户端的常规版本发布。

升级流程本身很简短。通过 PPA 安装的 Geth 可用 sudo apt upgrade 和 sudo systemctl restart geth 更新；使用 geth version 确认结果。Lighthouse 是单一二进制文件：重复第 3 步的下载流程，替换 /usr/local/bin/lighthouse，然后重启该 unit。重启前请务必阅读发行说明——参数标志偶尔会被重命名，而 systemd unit 中一个被重命名的标志，意味着服务会在凌晨两点拒绝启动。

同时也要为磁盘增长做好预算规划。截至 2026 年年中，Geth 的 full node 每周大约新增 10–15 GB；Lighthouse 的增长速度更慢。在 2 TB 的磁盘上，这是一个您可以重置的倒计时——启用 Merge 之前历史数据的过期机制可以释放几百 GB(参见故障排查部分)，而一次全新的 snap sync 能在一到两天内重建一个完全紧凑的数据库。使用 4 TB 存储时，增长将变成一个按年而非按季度考虑的问题。节点不必每一秒都保持在线，但离线时间越长，追赶进度所需的时间也就越长。

Full node 不是 validator

大家都听说过的那 32 ETH，属于 staking 的范畴，而非运行节点的范畴。本指南中的节点完全不需要任何 ETH——它对区块进行验证，也就是校验，这需要硬件成本，而非质押资金。

Validator 是与两个客户端并列运行的第三个程序：它持有签名密钥、生成 attestation 和区块，并因此获得奖励，同时需要配置一个用于接收收益的 fee-recipient 地址。这 32 ETH 是协议在出现可证明违规行为时可以罚没的抵押品。运维标准也随之提高——一个离线一个周末的 RPC 节点，周一恢复上线后追赶进度即可，而一个离线的 validator 则会在每个 epoch 都遭受小额罚金。

如果 ETH 不足 32 个，pooled staking 是入门方式：Rocket Pool 及类似协议允许无需许可的运营者以更小的保证金运行 validator，某些 pool 设置甚至就直接运行在上文搭建的那个节点之上。一个普通的 full node 不会产生任何收益。运行它是为了独立性和隐私、为了开发，或者作为日后 validator 所依托的基础。

安全性：端口布局即安全策略

这套搭建方案的整体安全模型，从第 1 步的防火墙规则中就可见一斑。30303 和 9000/9001 端口是开放的，因为 peer-to-peer 需要与陌生节点通信；8545 和 8551 端口绑定到 127.0.0.1，因为机器外部没有任何理由访问它们。JWT secret 用于验证 8551 端口上的 engine API 身份，但请将其视为第二道防线,而不是将端口对外开放的理由。

开放的 8545 端口是更严重的错误，因为 JSON-RPC 根本没有任何身份验证机制。扫描器能很快发现暴露的以太坊 RPC 端口，其危害不仅限于被人白嫖：如果启用了错误的 namespace,外部人员就能获取到本不该看到的调试内部信息和 mempool 内容。请将 --http.api 限制在 unit 中列出的这四个 namespace 范围内；对于任何 RPC 端口有可能被外部访问到的机器,admin、debug 和 personal 都应保持关闭。

当其他机器确实合理地需要访问 RPC 时，应使用隧道而非直接暴露：为自己使用 WireGuard 或 SSH 隧道，为小型团队使用带 TLS 和 IP allowlist 的 nginx 或 Caddy。得益于第 1 步的设置，客户端已经以无法登录的系统用户身份运行，因此即便客户端进程被攻破，也不会继承任何 shell 账户权限。为操作系统补丁添加 unattended-upgrades，服务器安全中那些枯燥的部分就能自行妥善处理。

故障排查

Lighthouse 无法连接到 Geth(“Unable to connect to execution endpoint”)

要么是 Geth 已经宕机(systemctl status geth)，要么是两者的 JWT secret 不一致。请确认两个 unit 指向的是同一个 jwt.hex 路径。如有疑问，重新生成一次 secret 并重启两个服务。

Geth 长时间卡在 “State heal in progress”

State heal 阶段会持续追赶链头，而随机写入性能较弱的磁盘永远也追不上。使用 fio 进行基准测试；您需要达到数万级别的 4k IOPS。SATA SSD 和默认配置的云盘是最常见的罪魁祸首。解决办法是使用真正的 NVMe 存储——没有任何参数标志能拯救一块速度太慢的磁盘。

Peer 数量始终为零

30303 端口(TCP 和 UDP)被阻挡，或未通过您的 NAT 正确转发。同时请检查系统时钟：timedatectl 应显示 NTP 同步处于激活状态，因为时钟偏差会破坏共识层一侧的 peer 握手过程。

磁盘空间被占满

首先找出增长来源：du -h --max-depth=2 /var/lib/geth。在 Geth 1.13 之前创建的 datadir 仍然使用旧的基于哈希的存储布局；干净的解决方法是进行一次全新的 resync，之后 state 会自动保持已 pruning 的状态。启用 Merge 之前历史数据的过期机制可以再释放几百 GB，而 ancient store 可以通过 --datadir.ancient 迁移到廉价的 HDD 上。

崩溃后 Geth 报告数据库损坏

断电、kill -9 或写入过程中遭遇 OOM kill，都会在下次启动时留下关于数据损坏或数据缺失的日志记录。有时重启即可解决；如果日志反复循环出现同样的问题，请停止尝试修复，转而进行 resync——将 datadir 移到别处，重新开始，snap sync 通常能在一到两天内重建全部数据，往往比任何修复尝试都更快。预防措施其实已经写进了 unit 配置中：TimeoutStopSec=600 给了 Geth 足够的时间进行 flush，而干净地执行 systemctl stop 是该进程唯一应该终止的方式。

OOM killer 终止了 Geth

journalctl -k | grep -i oom 可以确认这一怀疑。Geth 的 --cache 在主网上默认设置为 4096 MB，而同步期间的实际使用量会超过这一设定；再加上 Lighthouse 和操作系统本身的占用，一台 16 GB 内存的机器就会耗尽内存。请在小内存机器上设置 --cache 2048，并保留一个 swap 文件作为缓冲——宁可慢一点，也不要被杀掉，因为被杀掉的 Geth 不会执行任何 flush 操作，还会引发上文提到的数据库损坏问题。

自己运行节点，还是使用 API？

一个诚实的对比，毕竟 Chaingateway 卖的正是后一种替代方案。

当您需要重度、持续的原始 JSON-RPC 时——archive 查询、tracing、mempool 监控，或者最高级别的隐私性和抗审查能力——节点更胜一筹。节点是一项固定成本，却能支持无限量的请求——按成本部分提到的每月几百欧元的较低区间计算，一旦您的用量足够大，它就能击败任何按量计费的 RPC 方案。这也是理解以太坊真实运作方式的最佳途径。

而当节点只是达成目的的手段时，API 更胜一筹——对大多数企业而言，这个目的就是支付。已同步的节点能为您提供 eth_sendRawTransaction 和事件日志(event log)。但它不会为您提供按客户区分的存款地址、ERC-20 付款到账时的通知、密钥管理或重试逻辑。这些都是您需要在其之上自行构建和运维的应用层软件，而这通常比节点本身还要耗费更多的工时。

Chaingateway 的以太坊 API正是这块缺失的拼图：创建并导入地址(POST /api/v2/ethereum/addresses/import)、发送 ERC-20 代币(POST /api/v2/ethereum/transactions/erc20)，以及接收针对入账存款的 HMAC 签名 webhook——投递失败的记录会进入一个可查询的列表(GET /api/v2/ethereum/webhooks/notifications/failed)，并可通过重试 endpoint 重新发送。收支平衡点其实是一道算术题：服务器成本加上您搭建与运维所耗费的工时，对比/zh/pricing/上的某个套餐价格。对于支付类流程而言，这个不等式中 API 一侧的成本在远超个人爱好级别的规模下依然保持较低；而对于原始 RPC 的大量消耗场景，节点一侧则会较早胜出。可以从快速入门指南和 webhook 指南开始——无需 KYC 的 7 天试用期，足以让您端到端地测试一次完整的存款流程(在此注册)。

如果您还运行其他链？请查看 BNB Smart Chain 和 TRON 的相关指南。