メインコンテンツへスキップ
もしISP側でキャリアグレードNAT(CGNAT)が適用されている場合、ご自身のマシンへポートをフォワードすることは不可能です。なぜなら、フォワード先となる顧客個別のパブリックIPv4アドレスが存在しないからです。その代わりにモデルの隣で tokios-connector を実行してください。このツールは 外向き に https://api.tokios.com へ接続するため、パブリックIPもポートフォワードもルーターやISP側の設定変更も一切不要です。そうして得られるのは、どこからでも呼び出せる安定した認証済みエンドポイントです。
受信リクエストはパブリックIPやフォワード可能なポートが存在しないためISPのCGNATでブロックされる。一方tokios-connectorの外向き接続はその壁を通過し、Tokiosゲートウェイに到達する。

受信接続はISPのCGNATで遮断される — フォワード可能なポートが存在しないためだ。一方コネクターの外向き接続は問題なく通過する。

ご自身はCGNATの背後にあるだろうか?

わずか2分の確認で判明する。ルーターの管理画面を開き WAN(または インターネット)アドレスを確認した後、ifconfig.me のようなサイトが示すパブリックアドレスと比較してほしい。
  • WAN address between 100.64.0.0 and 100.127.255.255 — you’re behind CGNAT. That range (RFC 6598) is reserved specifically for carrier-grade NAT.
  • WANアドレスがプライベート範囲(10.x.x.x、172.16–31.x.x、192.168.x.x) — ルーターの上層に別のNAT層が存在し、受信トラフィックが同様にブロックされている。
  • WANアドレスがパブリックアドレスと一致 — 実際にパブリックIPを保有しており、従来のポートフォワーディングも少なくとも可能だ(ただしモデルのAPIは依然として公開インターネット上で認証なしの状態となる)。
上記の2つのケースのいずれかに該当する場合、どんなルーター設定を施しても受信トラフィックをマシンへ届けることは不可能だ。続きをお読みいただきたい。

なぜCGNATではポートフォワーディングが利用できないのか

ポートフォワーディングは「自分のパブリックIPの特定ポートに届いた通信を、LAN内の特定デバイスへ転送せよ」とルーターに指示する仕組みです。これが機能するためには、まずルーター自体がパブリックなIPv4アドレスを持っている必要があります。 しかしCGNAT環境下ではそうではありません。ISPには顧客数の方がパブリックIPv4アドレス数より多くなるため、多数の顧客をひとつの共有パブリックIPの背後にまとめ、各家庭にはプライベートアドレスを割り当てています。つまりルーターの「パブリック側」も実際にはISPの内部ネットワーク上のプライベートアドレスに過ぎず、ポートフォワーディングの設定に使えるような自宅向けの固有な受信用アドレスは存在しないのです。 つまり以下のような制限が生じます:
  • ルーターをどのように設定しても、ポート11434(あるいは他のどのポートも)を外部からの通信用に開放することは不可能です。
  • この問題は自宅側で解決できません。これはISP側の機器上の設定であり、利用者側では変更できないのです。
  • ISPに連絡して専用のパブリックIPを申請することも場合によっては可能ですが(多くの場合有料のビジネス向けプランとして提供される)、直接設定できるものでもなく、必ずしも提供される保証もありません。
このため「単にポートを開放すればいい」という方法は、多くの家庭用回線においてホームサーバーの選択肢になり得ず、その結果VPSを借りて通信の中継を行ったり、自分が管理するサーバーへリバースSSHトンネルを設定したりするような回避策が存在するのです。どちらも外部からの通信を受け入れるためには、常時稼働する別のサーバーを用意してセキュリティ対策も施す必要があります。一方で送信専用の接続であれば、この問題を迂回するのではなく根本的に回避できるのです。

スターリンク、5G、および集合住宅向けISP

CGNATは特殊なケースではなく、多くの種類の回線でデフォルトで利用されています:
  • スターリンクでは標準的な家庭向けサービスはCGNAT下に置かれており、パブリックIPv4アドレスは上位プランでのみ提供されます。スターリンク回線を利用してモデルを提供する場合、1日目からすでにポートフォワーディングは不可能な状態となります。
  • 4G/5Gホームインターネット(T-Mobile Home Internetなど)もほぼ例外なくCGNATが適用されており、一般向けプランではパブリックIPの利用は一切できません。
  • アパートメントや光ファイバーISPにおいて、建物共用のIPアドレスやISP側のNAT処理が行われたアドレスを提供される場合も同様の挙動となります。
下記の送信専用設定はどの環境でも同様に機能します。なぜならコネクターは受信用パスを一切必要としないからです。

送信専用の対処法

The tokios-connector never listens for inbound traffic. It opens a wss:// connection outward to Tokios, the same direction your browser already uses to load a webpage — so CGNAT, your router’s NAT, and most firewalls never see it as anything unusual.
1

いつも通りモデルをローカル環境で実行してください。

通常通りバックエンドを起動します。OLLAMA_HOST=0.0.0.0や全インターフェースへのバインドフラグ、ルーター設定の変更は一切不要です。例えばOllamaの場合は以下の通りです。
Leave it listening on http://127.0.0.1:11434 (Ollama’s default). Tokios also works with llama.cpp, vLLM, and LM Studio — see Supported backends.
2

コネクターをペアリングする

Sign in at tokios.com/console, open the Setup tab, and click Start pairing. Tokios shows a one-time claim code shaped TKS-XXXX-XXXX, valid for about 15 minutes.モデルを実行しているマシン上で、ご使用のOS向けのインストール用ワンライナーを実行してください。
Windows
macOS
Linux
すでにtokios-connectorがインストール済みの場合は、代わりにそのコードを直接入力してください。
Back in the console, approve the device on the Setup or Connectors tab. The connector’s token is delivered over the tunnel once approved — you never see it on screen or paste it into a file.
3

デプロイを登録する

In the Models tab, register your local model and choose a public name — for example, llama3-tunnel. Clients send this public name, not your backend’s local model id, in the model field of every request.
4

APIキーを作成する

In the Keys tab, click Create key. Optionally scope it to specific deployments with model-name patterns (comma-separated globs, * for all). Copy the sk-tok-… key now — it’s shown only once.
この手順においてルーターやISP、公開IPアドレスは一切関係ありません。コネクターが接続を試み、コンソールが承認すれば、モデルはもはや自社ネットワーク経由ではなくTokiosのエンドポイント経由で利用可能になります。

どこからでも利用可能

The model field is always your registered deployment name, never your backend’s local model id. See Use Claude Code for persisting these environment variables across sessions.
厳格な企業用ファイアウォールやキャンパスネットワークでも、逆方向のCGNATと同様の問題が生じます。つまり公開IPアドレスがあっても着信接続がブロックされてしまうのです。しかしコネクターは常に外向きの wss://接続のみを開始するため、例外申請なしでも同様の設定でファイアウォールの背後でも問題なく動作します。

モデルは引き続き自社のハードウェア上に存在し、エンドポイントはどこからでも利用可能です

CGNATではISPが自宅ネットワークへの着信接続を管理します。レンタルした中継機器やリバースSSHトンネルを使ってこれを回避するには別途サーバーを構築・強化する必要があります。コネクターを使えば着信接続の必要性が完全になくなります。一度接続を開始し承認すれば、以後はISPがIPアドレスをどう扱おうとも https://api.tokios.comがクライアント側で利用する安定したアドレスとなります。

クイックスタート

コネクターをペアリングし、最初のモデルを端から端まで登録してみましょう。

トンネル機能とTokiosの比較

LLMのストリーミング通信において、本製品がCloudflare Tunnel、ngrok、Tailscaleとどのように異なるかをご確認ください。

Tokiosを利用すべきケース

CGNATは制約条件の一つに過ぎません。この判断フレームワークでは、チーム規模やエージェントの互換性、ネットワーク分離要件、さらには他のツールがより適している状況なども考慮しています。