iceFetch は、Minecraft Bedrock サーバーが NetherNet（RakNet を置き換えた WebRTC ベースのトランスポート）で提示する ICE candidate を読み取ります。この処理は Cloudflare Worker 上で、シグナリング層だけで完結します。
近年の Minecraft Bedrock Dedicated Server (BDS) は、従来の RakNet(UDP) の代わりに transport=nethernet で動作できます。NetherNet は WebRTC ベースで、実際のゲームデータは暗号化された SCTP-over-DTLS のデータチャネルを流れ、接続はブラウザのピア接続とまったく同じように、SDP offer/answer と ICE candidate でネゴシエーションされます。
このネゴシエーション（シグナリング）は、BDS が TCP ポート上に開く小さな HTTP サーバー（例: 19132）で行われます。クライアントはサーバーを発見し、1 回の HTTP リクエストでセッション記述（SDP）を交換します。
GET /v1/join → { name, protocol, version, players, maxPlayers, … }
POST /v1/join/{networkId} → SDP answer（Content-Type: application/sdp）ICE candidate とは、ピアに到達し得るネットワークアドレスの候補 1 つのことです — IP・ポート・種別（host=ローカル/インターフェイスのアドレス、srflx=NAT 反射の公開アドレス、relay=TURN 中継）から成ります。ネゴシエーション時、双方が SDP に候補を列挙し、ペアを実際に試して通る経路を見つけます。
NetherNet サーバーに offer を送ると、その SDP answer にはサーバーに到達できる候補 — 実際にゲーム通信が使う UDP エンドポイント — が入っています。iceFetch はこれを取り出して表示します。
a=identity 属性）を生成します。BDS は identity の無い offer を拒否するためです。POST /v1/join/{networkId} に送ります。Cloudflare Worker には UDP も DTLS も WebRTC スタックもありません。iceFetch はシグナリングのハンドシェイクは完了できますが、メディアのハンドシェイクは決してできません — つまりサーバーの候補は読めても、ゲームセッションは開けません。クライアントではなく、診断／偵察ツールです。
| エンドポイント | 返るもの |
|---|---|
GET /api/info?host=&port= | サーバーの /v1/join メタデータ |
POST /api/offer | { candidates[], answer, iceUfrag, … } |
curl -X POST https://icefetch.tools.kt04.com/api/offer \
-H 'content-type: application/json' \
-d '{"host":"play.example.net","port":19132}'ボディのフィールド: host（必須）、port（既定 19132）、networkId（任意・10進 uint64）、tls（自動判定 — true/false で強制）、fresh（キャッシュ無視）。
NetherNet で動作するサーバー（transport=nethernet の BDS 1.21.60 以降、またはそれを前段に置くネットワーク）に限ります。純粋な RakNet(UDP のみ) のサーバーには照会する HTTP シグナリングエンドポイントがありません。
候補リストが空の 200 応答は、サーバーの UDP ポートプールが今まさに枯渇している（保留中のシグナリングセッションが多すぎる）ことを意味します。それらがタイムアウトすれば回復します。
候補はサーバー自身がゲームプレイ用に提示しているエンドポイントです。大規模ネットワークでは、プロキシされたホスト名の背後にあるバックエンドのゲームノード IP であることが多いです。