ノードを建てるという作業は、たいてい一度ではうまくいかない。どこかでつまずき、エラーログとにらめっこし、原因を探り、直す。その繰り返しだ。そして面白いことに、つまずくポイントの多くは「あらかじめ知っていれば避けられた」ものだったりする。
この記事は、私が2台目のノード(tencawffee.com)をクリーンに構築する過程で実際に踏んだトラブルを、一つずつ記録したものです。それぞれについて、どんなエラーか / 何が原因か / どう解決したか / 予防できるか の4点で整理しました。
過去ブロックの同期が進まない
どんなエラーか
ノードを起動して、過去ブロックの同期が始まった ── と思いきや、こんなエラーがログに流れ続けて、まったく前に進まない。
Error: query exceeds max block range 2000
何が原因か
CAWクライアントは、過去のブロックをまとめて取得しようとする。デフォルトでは「一度に10,000ブロック」を要求する設定になっている。ところが、多くのRPCプロバイダ(特に無料枠)は、一度のクエリで取得できるブロック数に上限を設けている。よくあるのが「2,000ブロックまで」という制限だ。「10,000ブロックください」という要求に対して、RPC側が「2,000までしか無理です」と拒否する。結果、同期が一切進まなくなる。
どう解決したか
ソースコードの中にある、取得ブロック数の定数を書き換える。
/var/www/(あなたのドメイン)/client/src/services/RawEventsGatherer/listenForRawEvents.ts
この中の値を、10,000から1,500に変更する。
// 修正前 chunkBlocks = 10_000 // 修正後 chunkBlocks = 1500
上限の2,000より少し余裕を持たせて1,500にしておくと安全だ。修正後、ビルドし直してノードを再起動すれば、同期が進み始める。
これは現時点でCAWの標準セットアップに残っている既知の問題で、新規に建てる人はほぼ全員が踏む。「最初からこの値を直しておく」と知っていれば慌てずに済む。ノードを起動する前に、先回りして1,500に変更しておくのがスマートだ。
ノードが登録されない（registered: false）
今回いちばん手こずった、本丸のトラブル。詳しい追跡の過程は別記事『影を追って ─ 登録されないノードの謎を解く』に書いたので、ここでは要点だけ。
どんなエラーか
ノードは動いている。同期も進み、ピアにも繋がっている。なのに、いつまで経っても登録状態がこうならない。
registered: false, instanceId: null,
そして、よく見るとログの中に、紛れるようにこんなエラーが流れていた。
[NftTransferWatcher] Poll error: 408 Request Timeout
"message":"Request timeout if you are on the free tier,
please upgrade your tier to the paid one"
何が原因か
L1(イーサリアムのテストネット)にアクセスするためのRPC(dRPCに設定した部分) ── ブロックチェーンに問い合わせる窓口 ── が、無料枠の制限でタイムアウトしていた。CAWの登録処理はL1上のコントラクトの状態を確認する処理を含むため、そのL1アクセスが詰まると、登録の前提が完了せず、登録そのものが始まらない。
決め手は、ブロックチェーンエクスプローラー(BaseScan)でバリデーターアドレスを見たことだった。「送信された取引：該当なし」── 登録に失敗しているのではなく、そもそも登録を試みていないとわかった。そしてログを丁寧に追うと、L1アクセスのタイムアウトが頻発していた。ここが詰まっているせいで、登録の前提となるL1確認が完了していなかったのだ。
じつはこの原因にたどり着けたのは、私がたまたま2台のノードを運用していて、片方(1台目)は問題なく登録できていたからだ。1台目はこのタイムアウトが一切出ていなかった。同じソフト・同じ無料枠なのに、なぜ2台目だけ詰まるのか ── 突き詰めると、RPCのキーごとに利用状況が管理されていて、2台目のキーだけが制限に達していた。
もしあなたがこれから建てる1台目で同じ症状(動いているのに registered: false のまま)に出くわしたら、台数を比べる必要はない。まずL1用RPCのタイムアウトを疑ってほしい。これは私が2台運用して回り道した末に掴んだ結論を、先回りして渡しておくものだ。
どう解決したか
詰まっていない別のRPCプロバイダの無料枠を新しく用意して、L1用のエンドポイントを差し替えた。
ここで一点、判断のポイントがある。「1台目と同じキーを使い回せばいいのでは?」と思ったが、やめた。1台目のキーに2台分の負荷を集中させると、今度は1台目まで詰まる危険があるからだ。動いているものに余計なリスクを背負わせない── これは大事な原則だと思う。dRPCから他のRPCに私が乗り換え先に選んだのは Chainstack だった。差し替えて再起動したところ、滞っていた登録処理が一気に流れ、registered: true / instanceId: 245 を取得できた。
ノードを建てる前に、L1用のRPCを最初から余裕のあるプロバイダにしておくこと。選ぶポイントは「月単位で十分な余裕があること」「WebSocket(wss)とHTTP(https)の両対応」の2つ。そして将来もし2台目以降を建てるなら、ノードごとにRPCキーを分けると、片方が詰まってももう片方は無事でいられる。何より、最初の1台でこのRPC設定さえ押さえておけば、今回の「動いているのに登録されない」という一番やっかいなトラブルは、丸ごと回避できる。ただし、何が起こるかわからない部分はある。RPCの今回の件が逆になるかもしれない。ChainStackからdRPCに代えるっていう可能性もあるかもしれない。その時に応じた行動を予め用意しておくとスムーズに進むだろう。
CORSエラー（他から接続できない）
登録が完了して安心したのも束の間、今度は別の赤いエラーが流れ始めた。
どんなエラーか
Error: Origin https://test.caw.social not allowed by CORS
これが、ほぼ1秒おきに延々と繰り返される。
何が原因か
CORS(クロスオリジン)は、「どのWebサイトからのアクセスを許可するか」を制御する仕組みだ。ノード側に「許可するアクセス元(オリジン)のリスト」があり、そこに載っていないサイトからのリクエストを拒否する。登録が完了してノードがネットワークに公開されたことで、公式のテストネット用フロントエンド(test.caw.social)が私のノードのAPIにアクセスしに来るようになった。ところが許可リストにそのアドレスが入っていなかったため、片っ端から弾いていた。せっかく登録されて一人前になったのに、訪ねてきた客を門前払いしているような状態だった。
どう解決したか
設定ファイル(.env)の ALLOWED_ORIGINS という項目に、公式フロントエンドのアドレスを追加する。確認してみると、2台目にはこの行がそもそも存在していなかった。1台目には設定済みだったのに、2台目を作るときに抜け落ちていたのだ。
ALLOWED_ORIGINS=https://test.caw.social,https://(あなたのドメイン)
公式フロントエンドのアドレスと、自分のドメインの両方を含めるのがポイント。保存して再起動したら、CORSエラーはぴたりと止まった。
ALLOWED_ORIGINS に公式フロントエンドのアドレスを含めておくことは、初期設定の一部として組み込んでおくべきだ。「2回目だから大丈夫」と思っていると、こういう基本的な設定ほどするりと抜け落ちる。だからこそ、自分の手順を記録しておくことが効いてくる。
初期設定でまとめて回避するチェックリスト
ノードを建てる最初の段階で設定しておけば、後で慌てずに済むこと。未来の自分と、これから建てる誰かのために。
起動前にやっておくこと
- chunkBlocksを1,500に変更しておく（トラブル01の予防）
- L1用RPCを余裕のあるプロバイダにする。wssとhttpsの両対応を確認（トラブル02の予防）
- 複数ノードならRPCキーをノードごとに分ける（トラブル02の予防・切り分けのしやすさ）
- .envの ALLOWED_ORIGINS に公式フロントエンドと自分のドメインを設定（トラブル03の予防）
設定変更するときの鉄則
- 変更前に必ずバックアップを取る。
cp .env .env.bak.(日付)の一手間が、いざというとき自分を救う
エラーログを読むときの心構え
今回の3つのトラブル、振り返ると共通点がある。答えは、最初からログに書いてあったということだ。
「query exceeds max block range 2000」── ブロック範囲が大きすぎる、と言っている。「please upgrade your tier」── 無料枠の制限だ、と言っている。「not allowed by CORS」── 許可されていない、と言っている。エラーメッセージは、たいてい正直だ。面倒がらずに読めば、原因の半分はそこに書いてある。
そして、もう一つ伝えたいことがある。今回のトラブルの多くは、私がたまたま2台のノードを運用していたからこそ、原因を早く突き止められた。動いている個体と、つまずいた個体。その差分が、答えへの最短ルートだった。
とはいえ、これから初めてノードを建てる人にとって、最初から2台を並べて比べるのはハードルが高い。だからこそ、この記事を残している。私が2台運用して回り道した末に掴んだ知見を、あなたが1台目で先回りして使えるように。上のチェックリストは、まさにそのための地図だ。比べる相手がいなくても、ここに書いたポイントを最初から押さえておけば、同じ落とし穴は避けられる。
この地味な4つを、面倒がらずに繰り返すこと。
それが、闇の中で躓いたときに、もう一度立ち上がるための、いちばん確かな方法だと思う。
次に建てるとき、私はきっとこの記事を読み返す。「ああ、あのとき苦労したな」と思いながら、今度はもっと早く、躓かずに歩けるはずだ。
記録とは、未来の自分への手紙でもある。
