在獨立伺服器上運行 Chainstack 節點
在不與他人共用的裸機上自架你自己的 full node 或 archive node。把節點帶到 Chainstack(BYOC),從第一天起就擁有 root 與 IPMI,並擺脫託管 endpoint 的速率限制。
在獨立伺服器上用 Chainstack 能做什麼
Chainstack 是支援 70 多條鏈的託管區塊鏈基礎設施。若運行專用伺服器,您需自行處理節點,而 Chainstack 的工具則負責管理該節點。
沒有速率限制的 full node 或 archive node
Bring Your Own Cloud(BYOC)
dApp 或 RPC 的正式環境後端
大規模索引 — 每一筆交易,不抽樣
Validator 或質押節點
在一台機器上整合多條鏈的節點
如何在獨立伺服器上部署 Chainstack 節點
以太坊的 full node 同步需要數小時到數天,archive node 則需要好幾 TB。以下步驟會帶你從一台空機器,走到一個正在同步、且 RPC endpoint 已可運作的節點。加固、監控和 reverse-proxy 設定列在最後的後續步驟中。
步驟 01 — 下訂伺服器並取得存取權
從上方區塊選一個配置(單一條鏈的 full node 用較小的 NVMe 等級即可)。開通完成後,你會透過電子郵件收到 IP、root 密碼和 IPMI 資訊。用 SSH 連線:
ssh root@YOUR_SERVER_IP如果作業系統無法開機,IPMI 讓你不必開支援工單,就能重新安裝系統或進入 console。
步驟 02 — 為鏈上資料準備 NVMe
確認磁碟已存在,並掛載要用來存放鏈上狀態的那一顆:
lsblkmkfs.ext4 /dev/nvme1n1mkdir -p /data/ethereummount /dev/nvme1n1 /data/ethereumecho '/dev/nvme1n1 /data/ethereum ext4 defaults 0 0' >> /etc/fstab把鏈上資料放在專用的 NVMe 上,而不是系統磁碟。
步驟 03 — 安裝執行客戶端
從官方 PPA 安裝 Geth:
add-apt-repository -y ppa:ethereum/ethereumapt update && apt install -y ethereumgeth version步驟 04 — 安裝共識客戶端
The Merge 之後,以太坊需要在 Geth 旁邊搭配一個共識客戶端。安裝 Lighthouse,並產生兩個客戶端用來互相驗證的共用 JWT secret:
openssl rand -hex 32 | tr -d '\n' > /data/ethereum/jwt.hex把 Lighthouse 指向 Geth 在 8551 埠的 engine API。
步驟 05 — 啟動 Geth 並開放 RPC endpoint
讓 Geth 指向 NVMe 上的路徑,並啟用 HTTP-RPC API:
geth --datadir /data/ethereum \ --authrpc.jwtsecret /data/ethereum/jwt.hex \ --http --http.api eth,net,web3 \ --http.addr 0.0.0.0 --http.port 8545綁定到 0.0.0.0 會把 endpoint 開放在所有網路介面上—在你驗證階段沒問題,但上正式環境前要限制存取。
步驟 06 — 以服務方式運行並確認同步
把 Geth 包成一個 systemd unit,讓它在重開機後仍能運行、並在故障時重新啟動,然後觀察同步開始:
systemctl enable --now gethgeth attach --exec 'eth.syncing'同步過程中,你會看到區塊編號逐漸上升:
{ currentBlock: 2148740, highestBlock: 21463991, ...}當 eth.syncing 回傳 false 時,節點已完全同步,RPC endpoint 也已上線。
步驟 07 — 驗證 endpoint 是否回應
從你的應用程式伺服器,確認節點會回應 JSON-RPC 呼叫:
curl -s -X POST http://YOUR_SERVER_IP:8545 \ -H "Content-Type: application/json" \ -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'回應中出現十六進位的區塊編號,代表你的自架節點正在處理請求。
後續步驟(上正式環境前請完成): 用 UFW 和 reverse-proxy 限制 RPC 埠、加上 TLS、為 peer 數量和磁碟使用量設定監控,並且—如果你使用 Chainstack BYOC—把節點連到你的 Chainstack 專案,讓它顯示在 console 裡。
常見問題
同步看起來卡在某個很低的區塊好幾個小時。 這通常是狀態下載階段的正常現象,而不是故障。在 geth attach 中用 admin.peers.length 檢查 peer 數量—如果是零,代表你的防火牆擋住了 P2P 埠(30303)。把它打開,peer 就會出現。
磁碟填滿的速度比預期快。 你不小心部署了 archive node。full(「snap」)同步只保留近期狀態;archive 會保留全部,需要好幾 TB。確認節點是用哪種模式啟動的,並依模式來決定 NVMe 容量,而不是反過來。
RPC endpoint 拒絕來自你應用程式的連線。 Geth 預設只監聽 localhost。要嘛是啟動時沒有加 --http.addr 0.0.0.0,要嘛是防火牆規則擋掉了 8545 埠。在判定節點故障之前,先檢查這兩點。
is*hosting 的基礎設施是 Chainstack 的穩固基礎
是裸機,而不是它的一小塊
你會完整取得一顆多核心的 AMD EPYC 和數百 GB 的 RAM,你和磁碟之間沒有任何 hypervisor。節點同步受限於 I/O,而在獨立伺服器上,沒有其他東西會來搶磁碟。從第一次開機起就提供 root 和 IPMI。
為鏈上狀態打造的 NVMe
archive node 會對磁碟產生持續的隨機讀取,這類負載會很快耗損消費級 SSD。我們採用多顆磁碟配置的企業級 NVMe,並在部署時設定 soft-RAID—正是為這種情境而準備。
內含 DDoS 防護與免費遷移
在荷蘭,我們提供防護效果達 95% 的免費 DDoS 防護;若你從其他供應商搬過來,我們免費為你遷移專案。這一切都運行在我們自有的硬體上,位於五個地點的 Tier-3+ 資料中心,全天候 24/7 監控。