IP Router
仕組み · 入門

サイトはIPで判断する。これはエージェントが着る出口IPを選ぶ交換機。

ネット上の機器には住所がある。検索、店、広告、ニュースはそれで見せるものを決める — 通貨、言語、順位、ページが開くかどうか。データセンターのAIエージェントの住所は、そのデータセンターひとつ。ローカル出口がなければ、どの fetch も同じ建物から出たように見える。

国か都市を指定する。IP Router がそこに出口を選び、そのIPからリクエストを出し、ページを返す。JSONエージェントも本物のブラウザも同じ頭脳。

リクエストを試すユースケースへ
考え方

事実は4つ。あとは使える。

サイトはノートPCを見ない

見えるのは出口IP。出口を変えればページが変わる — 価格、SERP、店舗検索、ペイウォール。

国は言語ではない

cc-JP は日本のIPに載せる。lang-ja はサイトに日本語を読むと伝える。普通は両方いる。

Sticky は「同じ人」

途中でIPが変わるとログイン、カート、cookie は死ぬ。sessid は期限まで出口に釘付けする。

扉は2つ、カーネルは1つ

エージェントは /api/v1/fetch に JSON を POST。ブラウザと curl は :7777 で CONNECT。どちらも selectRoute を呼ぶ。

用語

コンソールが使う十数語。

IP / 出口
サイトが見るアドレス。ノートPCでも、エージェントのホストでもない — IP Router を出た最後の hop。
cc（国）
ISO の国コード。GB はイギリス、DE はドイツ、JP は日本。これで市場を選ぶ。
city（都市）
国より細かい。ロンドンとマンチェスター、ニューヨークとオースティン。ユーザー名では空白がアンダースコアになる：city-new_york。
lang（言語）
Accept-Language ヘッダ。サイトの「どの言語を読むか」という問い。IP とは独立。
sessid（sticky）
仕事の各 hop が同じ出口を使うよう、再利用する名前。既定の TTL は 10 分。sesstime がそれを上書きする。
type（種別）
出口のネットワークの種類：residential、datacenter、mobile、または ISP。サイトはこれらを別物として扱う。
pool（プール）
追加したノードの一覧。それぞれ国、場合によっては都市が付く。ルーターはターゲティングをノードに合わせる。
backconnect（バックコネクト）
ベンダーのゲートウェイがひとつ。IP Router はそのベンダーのユーザー名に -cc-US-city-austin-sessid-job1 を付ける。
direct（ダイレクト）
このマシン。学習には十分。サイトが見るのは依然ホストの IP なので、geo のページは変わらない。
IP farm
都市に並べる Android のスマホ。エージェントはその last-mile から出る。課金は稼働中の接続ごと — GB ごとではない。
Fetch API
JSON で POST /api/v1/fetch。HTTP CONNECT を話さないエージェントと LLM 向け。
ゲートウェイ :7777
HTTP プロキシ。curl -x、Playwright、ブラウザ。ターゲティングはユーザー名に入る。Oxylabs 方式。
2つの扉

同じターゲティング。違うクライアント。

クライアントの話し方に合う扉を選ぶ。ターゲティングはどちらでも同じ。

Fetch API — エージェントの扉

クライアントが JSON を POST するときに使う：LLM ツール、スクリプト、n8n ノード、Playground。

Bearer キーで POST /api/v1/fetch。国、都市、言語、セッションを body に入れる。レスポンスにはページ、出口の geo、route.reason が含まれ、その hop が選ばれた理由が分かる。

URL を取得して本文を返す。クリックも、フォーム入力も、本物のブラウザの cookie ジャーも持たない。本物のブラウザで決済するなら、ゲートウェイを使う。

HTTP ゲートウェイ — ブラウザの扉

クライアントがすでに HTTP プロキシを話すときに使う：curl -x、Playwright、Chrome、CONNECT を期待するスクレイパー。

プロキシを host:7777 に向ける。ユーザー名は iprouter-{keyId}-cc-GB-city-london-sessid-job1。パスワードは API キー。fetch の body と同じターゲティングトークンが、ユーザー名の中にあるだけ。

CONNECT は HTTPS ヘッダを書き換えられない。TLS サイトで Accept-Language が要るなら、ブラウザ（または Fetch API）が送る。ユーザー名の lang- はルーティングと HTTP へのヒントであり、HTTPS への魔法の注入ではない。

あなたが使う
JSON エージェント / LLM ツールFetch API
Playground / URL を試すFetch API
curl、Playwright、本物のブラウザゲートウェイ :7777
ログインしてから同じセッションをクロールどちらの扉でも、加えて sessid
出口

リクエストが実際に出ていく場所。

出口とは、サイトから見てリクエストがインターネットへ出ていく場所。「このマシン」以外の出口が少なくともひとつないと、geo のページは変わらない。

Direct — このマシン

ノードに最初から入っている。Playground が動くよう、リクエストはすぐ成功する。route.reason は「direct」または「direct fallback (no geo node)」と言う。サイトが見るのは依然ホストの IP。

Pool — 追加した IP

コンソール → プロキシ pool。各ノードには国、任意の都市、type がある。ロンドンを頼めば、ロンドンの pool ノードが勝つ。都市なしで GB を頼めば、どの GB ノードでも勝つ。

Backconnect — ベンダーのゲートウェイひとつ

ゲートウェイをひとつ追加する。IP Router はユーザー名にターゲティングを注入する（-cc-DE-city-berlin-sessid-s1）。IP をひとつずつ並べる代わりに、プロバイダから帯域を買うときに使う。

IP farm — 都市のスマホ

Android のスマホを並べ、サイトに国と都市を付け、稼働中の接続数を決める。エージェントはその last-mile から出る。課金は接続あたり月額。14日の試用が最初の1台を覆う。

国を名指しすると、ルーターはこの順で試す：city pool match → country pool match → backconnect geo injection → direct fallback。有効なプロキシがひとつもなければ 422 であり、静かな見逃しではない。

プロキシ poolIP farmルーティングツリー
最初の試し

5分。有料の出口はまだ要らない。

ガイドの残りを抽象のままにしないため、これを一度やる。5分。有料の出口はまだ要らない。

  1. 01
    コンソールを開く

    Landing → コンソールを開く。ローカルには登録がない。着地するのは概要。

  2. 02
    echo の URL を送る

    Playground にはローカルの echo が最初から入っている。国を選ぶ（US でよい）。セッションは agent-demo のまま。送信。echo からは必ず 200 が返る — これは扉の証明であり、geo の証明ではない。

  3. 03
    3つのフィールドを読む

    ok は true であるべき。route.reason は選ばれた出口を伝える。geo.exit は外の世界が見る IP — direct では空か、このマシン。

  4. 04
    マシンの IP を離れる

    プロキシ pool に pool か backconnect のノードを足すか、気になる都市に IP farm を足す。もう一度送る。reason はもう「direct fallback」と言うべきではない。

  5. 05
    キーをコピーして扉を選ぶ

    Fetch API 用の API キー。Endpoints がゲートウェイのユーザー名を作る。エージェントには LLM ツールの schema がある。同じターゲティング、見た目は3つ。

ユースケース

仕事ごとの動き。

つまみは毎回同じ：国、都市、言語、sticky、type。仕事で変わるのは、どれを回すかと、どの扉を通るかだけ。行を選ぶ。

都市 / 国

その都市の人が見る検索を見る

Google（と Bing、maps）はひとつのネットを出さない。立っている場所からのネットを出す。順位、local pack、広告、表記まで — 出口IPと言語ヘッダに乗る。エージェントが米国データセンターから fetch すれば、採点するのは米国の結果ページだ。「マンチェスターではどう見えるか」と聞いても同じ。

IP Router なし

見えるのはホスト国の SERP。バージニアの VM からロンドンを検索しても、ロンドン型のクエリ文字列が付いたバージニアのページのまま。

あり

cc-GB + city-london + lang-en_GB。hop は英国の出口から出て、Accept-Language はイギリス英語。ページはロンドンの訪問者が得るもの。

仕組み

  1. 01市場を名指し：国 GB、都市 London、言語 en-GB。都市は重要 — Manchester と London の local pack は違う。
  2. 02エージェントが読む HTML/JSON なら Fetch API。ヘッドレスブラウザが SERP を運転するなら gateway。
  3. 03ページ送りやクリックなら安定した sessid。途中の新セッションは別の訪問者に見える。
  4. 04route.reason を読む。欲しいのは city pool match（または backconnect geo injection）。Direct fallback はまだホストにいる。
  5. 052回を比べる：同じクエリで US と GB。local pack と広告は動くはず。動かなければ、まだ geo の出口に乗っていない。
扉

どちらの扉でも。エージェントが JSON を出すなら Fetch。クライアントが CONNECT なら gateway。

cc-GBcity-londonlang-en_GB
Fetch API
{
  "url": "https://www.google.com/search?q=best+coffee+near+me",
  "geo": { "country": "GB", "city": "London", "language": "en-GB" },
  "session": "serp-london"
}
ゲートウェイ :7777
curl -x http://iprouter-key_dev-cc-GB-city-london-lang-en_GB-sessid-serp-london:ipr_live_dev_key@127.0.0.1:7777 https://www.google.com/search?q=best+coffee+near+me
成功したと分かるとき

route.reason は geo ヒット、geo.exit はホストではなく、local pack はロンドンの店を名指しする — サーバーの隣の店ではない。

よくある失敗

  • 国だけ。都市なしの GB だと、欲しかった local pack がない全国ページに着地することが多い。
  • lang がない。en-US 付きの英国 IP は、まだアメリカ式の綴りと、混ざる米国プロパティに寄る。
playground で試すエージェント schemas
route.reason

geo が本当に起きたかを伝える一文。

city pool match
都市を頼み、その都市の pool ノードが有効だった。最良の geo ヒット。
country pool match
都市ノードがない（または都市を頼まなかった）が、その国の pool ノードが有効だった。
backconnect geo injection
その国の pool ノードがない。backconnect のゲートウェイがオンなので、ターゲティングがそのユーザー名に書き込まれた。
direct fallback (no geo node)
その国には何もない。リクエストは出た — このマシンを通って。geo のページは変わらない。ノードか farm を足す。
sticky session
sessid を再利用し、古い出口がまだ有効だった。前回と同じ IP。TTL は更新された。
backconnect rotate / pool rotate / direct
国を名指ししなかった。ルーターは合う出口をどれか選び、セッションを送っていればその選択をハッシュして固定する。
失敗

製品のバグに見えるもの。

国だけで言語がない

日本の IP に英語の Accept-Language だと、まだ英語が出ることが多い。cc だけでなく lang（または fetch の body の language）も設定する。

リクエストごとに新しい sessid

セッション文字列が変わると、別人になる。ログインは落ちる。仕事全体で同じ sessid を再利用する。

direct fallback を信じること

このマシンの echo が 200 でも、geo の証明ではない。route.reason を読む。direct fallback とあれば、サイトが見たのはまだホスト。

データセンター対 residential

一部のオリジンは ASN を指紋する。ページが captcha の壁や「datacenter detected」の空白なら、type-residential にするか IP farm を使う。

HTTPS + ゲートウェイ + lang

ゲートウェイは HTTPS の CONNECT トンネルに Accept-Language を注入できない。クライアントからヘッダを送るか、Fetch API を使う。

空の pool

すべてのノードが無効なら、422「No enabled proxies in the pool.」になる。direct ノードを有効にするか、オンのノードをひとつ足す。