OpenClaw で CPU/RAM 使用率が高く、ゲートウェイが再起動する場合:Telegram で IPv6 を無効に

あなたのOpenClawインスタンスで、最近のバージョン(特にTelegram統合時)に高いCPU/RAM使用率、応答の遅延、定期的なゲートウェイ再起動が発生している場合、原因はautoSelectFamily: true(Node 22+のデフォルト)かもしれません。r/openclawのユーザーが、IPv6接続の失敗がリソースリークを引き起こしていることを突き止めました。
問題
OpenClawのTelegram統合はNode 22+でデフォルトでautoSelectFamily: trueになり、IPv4とIPv6の両方の接続を同時に試行します。ネットワークスタックがIPv6に対応していない場合、これらの接続はENETUNREACHで失敗し、イベントループの停止に連鎖します。症状は以下の通りです:
- 80秒間のイベントループフリーズ
- CPU使用率が約52%で張り付く
- 1日あたり約9回のゲートウェイ再起動
sendChatActionの失敗
修正方法
Telegramボット設定で、autoSelectFamily: false(IPv4のみの接続を強制)とdnsResultOrder: 'ipv4first'の両方を二重の対策として設定します。設定例:
// OpenClaw Telegramボット設定内
clientOptions: {
autoSelectFamily: false,
dnsResultOrder: 'ipv4first'
}
結果
修正適用後、ユーザーは以下を報告しました:
- liveness警告0件
- ERRORレベルのログエントリ0件
- 5時間以上再起動0回
sendChatActionの失敗0件- CPU使用率が52%から4.4%に低下
- イベントループのフリーズなし
複数のTelegramボットを実行している場合、問題がより顕著になる可能性があります。この修正は、Node 22+でTelegramを使用するすべてのOpenClawバージョンに適用可能です。
📖 全文を読む: r/openclaw
👀 See Also

Claude Codeワークフローポストの盲点:リカバリ、制約、権限管理
よくある「Claude Codeワークフロー」の投稿はハッピーパスばかりですが、不適切な編集からの復旧、制約の強制、権限管理といった、実運用で重要な要素が欠けています。

モデルルーティングがClaude Maxサブスクリプションと比較してAPIコストを85%削減——開発者による分析
Claude Maxの加入者がトークン使用量を追跡したところ、Opusが必要だったタスクはわずか15%であることが判明。APIルーティング(日常タスクはSonnet、高度な推論はOpus)に切り替えたところ、月額コストが200ドルから約30ドルに削減され、出力品質は同一だった。

OpenClawトークン使用調査により設定上の問題が明らかになりました
ある開発者がOpenAI Codexの週間サブスクリプションを1.5日で使い切り、Claude Codeを使用して設定上の問題を特定しました:すべてのメッセージで発火するTelegramボット、生のCSS/JSを返すウェブフェッチ、蓄積する孤立セッションファイル。

Claude Codeを使ったプレコーディングルーチン:コードを書く前に5つのMCPサーバー
ある開発者が、5つのMCPサーバー(メモリ、コードベースグラフ、Tavily検索、Context7ドキュメント)とセーフティフックを使用し、幻覚や無駄な編集を劇的に減らす60〜90秒のルーティンを公開しています。