AdsPower と Multilogin でプロキシを設定する方法（2026）

AdsPower と Multilogin は、GoLogin と Dolphin Anty に次いで最もよく質問されるアンチディテクトブラウザです。フィンガープリント側はブラウザが処理してくれます — canvas、WebGL、フォント、audio context — が、IP は依然としてあらゆるプラットフォームが最初にチェックする要素です。フラグの付いた IP や共有 IP 上では、完璧なフィンガープリントであってもアカウントは紐付けられ、結局 BAN されてしまいます。

このガイドでは、両ブラウザでのプロキシ設定を順を追って解説します — 単一プロファイル、ファーム向けの一括インポート、検証、そして実際に BAN を引き起こす失敗パターンです。GoLogin や Dolphin Anty を使っている場合は、GoLogin & Dolphin Anty 設定ガイドを参照してください。

始める前に：必要なもの

プロキシプロバイダーのダッシュボードから 4 つの値が必要です。JIBAO Proxy では次のようになります：

• ホスト：us.jibaoproxy.com（リージョン別ゲートウェイ）
• ポート：913（HTTP と SOCKS5 の両方に対応）
• ユーザー名：アカウントのユーザー名。任意で国やセッションのパラメータを付与
• パスワード：プロキシのパスワード

単一の接続文字列として：socks5h://USERNAME:[email protected]:913

何かを設定する前に決めておくこと：スタティックかダイナミックか。数ヶ月維持する予定のアカウント（SNS、マーケットプレイスの出品者アカウント、広告アカウント）には、プロファイルごとに 1 つのスタティック住宅 IP を使います — プラットフォームは安定した IP を信頼シグナルとして扱うからです。バッチで作成して使い捨てるアカウントには、スティッキーセッション付きのダイナミック住宅 IP の方が安価で、バッチごとに新しい IP が得られます。

AdsPower のプロキシ設定

ステップ 1：プロファイルの作成または編集

1. AdsPower を開き、New Profile をクリックします。
2. 特定のサイト（Facebook、Amazon、TikTok）を狙う場合はプラットフォームプリセットを選択します — AdsPower はプラットフォームごとに一部のデフォルトを調整します。
3. Fingerprint settings では、理由がない限りデフォルトのままにしておきます。プロファイルごとにランダム化される設定が望ましいです。

ステップ 2：プロキシの設定

1. プロファイルエディタの Proxy セクションまでスクロールします。
2. Proxy type を SOCKS5 または HTTP に設定します。
3. 次を入力します：
   • Proxy host：us.jibaoproxy.com
   • Proxy port：913
   • Proxy username：USERNAME-session-profile001 — セッションのサフィックスにより、このプロファイルはセッションの存続期間中 1 つの IP に固定されます。プロファイルごとに必ず異なるセッション ID を使ってください。
   • Proxy password：パスワード
4. Check proxy をクリックします。AdsPower が出口 IP、国、レイテンシを表示します。

AdsPower は type://user:pass@host:port 形式の 1 行貼り付けにも対応しています — socks5://USERNAME:[email protected]:913 をホストフィールドに貼り付ければ、残りが自動入力されます。

ステップ 3：タイムゾーンと言語を IP に合わせる

Fingerprint settings で、Timezone を Based on IP、Language を Based on IP に設定します。これは AdsPower 設定で最もよくあるミスです：米国プロキシなのに、マシンの実際のタイムゾーンが Asia/Shanghai のままだと、即座に不整合フラグが立ちます。AdsPower は両方をプロキシから自動的に導出できます — これをオンにして放っておきましょう。

ステップ 4：一括インポート（ファーム向け）

50 以上のプロファイルを運用していますか？プロキシを 1 つずつ設定してはいけません：

1. Profiles → Import に進み、XLSX テンプレートをダウンロードします。
2. プロキシの列を host:port:username:password 形式で埋めます。プロファイルごとに 1 行、それぞれユーザー名に固有のセッションサフィックスを付けます（USERNAME-session-p001、USERNAME-session-p002、…）。
3. インポートします。AdsPower が行ごとにプロキシを付与したプロファイルを 1 つずつ作成します。

Multilogin のプロキシ設定

Multilogin（現 Multilogin X）はブラウザプロファイルごとにプロキシを処理し、プロファイル作成フローに接続チェックが組み込まれています。

ステップ 1：プロファイルの作成

1. New profile をクリックし、Mimic（Chromium）または Stealthfox（Firefox）を選びます。Mimic の方が安全なデフォルトです — ほとんどの実ユーザーは Chrome を使っています。
2. プロファイルには「test1」ではなく、保持するアカウントにちなんだ名前を付けます — 3 ヶ月後にはこれが 80 個になっているからです。

ステップ 2：プロキシの設定

1. プロファイルエディタで Proxy タブを開きます。
2. 接続タイプとして SOCKS5（または HTTP）を選択します。
3. 次を入力します：
   • Address：us.jibaoproxy.com
   • Port：913
   • Username：USERNAME-session-ml001
   • Password：パスワード
4. Check proxy をクリックします。Multilogin が接続性を検証し、外部 IP と国を表示します。

ステップ 3：Multilogin にフィンガープリントを IP へ同期させる

Multilogin はプロキシのジオロケーションを読み取り、タイムゾーン、ジオロケーション API、WebRTC のパブリック IP をそれに合わせて設定するよう提案します。3 つすべてを承認しましょう。Multilogin の WebRTC マスキングは、WebRTC を無効化するのではなく、実際の IP をプロキシ IP に置き換えます — これは無効化された WebRTC よりも自然に見えます。無効化された WebRTC それ自体が（弱いながらも）ボットシグナルになるからです。

ステップ 4：実運用前に検証する

プロファイルを起動し、新しいプロファイルごとにこのチェックリストを 1 回実行します：

1. IP チェック — 表示される IP は、実際の IP ではなくプロキシ出口でなければなりません。
2. タイムゾーンの一貫性 — ブラウザのタイムゾーンが IP の国と一致していること。
3. WebRTC — ローカル IP や実際のパブリック IP が漏れていないこと。
4. DNS — リゾルバはローカルの ISP ではなくプロキシ経路に属しているべきです。（SOCKS5 では、DNS がプロキシ経由で解決されるよう socks5h セマンティクスを使います。）

AdsPower vs Multilogin：プロキシ処理の比較

機能	AdsPower	Multilogin
プロファイルごとのプロキシ	あり	あり
1 行貼り付けのパース	あり（type://user:pass@host:port）	なし（個別フィールド）
プロキシ付き一括インポート	XLSX テンプレート	API / CSV（X プラン）
IP からのタイムゾーン	あり、オプトイン	あり、チェック時に提案
WebRTC の処理	置換 / 無効化	プロキシ IP で置換（推奨）
組み込みプロキシチェック	あり	あり

ユースケース別のプロキシタイプ

ユースケース	プロキシタイプ	理由
長期的な SNS アカウント	スタティック住宅	毎回同じ IP でログイン。出品者/広告アカウントでの IP 変更はレビューを誘発する
アカウント作成のバッチ	ダイナミック住宅、スティッキー 10–30 分	バッチごとに新しい IP、サインアップフロー中は安定
プロファイルのウォームアップ	スタティック住宅	一貫性こそがウォームアップの全目的
リサーチ / スクレイピング用プロファイル	ダイナミック住宅、ローテーティング	セッション状態が不要、IP の多様性を最大化

料金の参考：スタティック住宅は帯域無制限で 1 IP あたり月 $4、ダイナミック住宅は GB 課金（$2/GB、デポジットボーナスで割安に）。詳細は料金ページを参照してください。

トラブルシューティング

どちらのブラウザでも「Proxy check failed」

• プロトコル/ポートの不一致が原因第 1 位です — プロキシタイプのドロップダウンがエンドポイントの想定と一致しているか確認しましょう。
• 認証情報はダッシュボードからコピーします。パスワードフィールドの末尾スペースは、エラーを出さずに失敗します。
• 同じ認証情報をターミナルから curl -x で試します。curl で動くなら、問題はプロキシではなくブラウザのフィールドにあります。

プロファイルは機能するが、アカウントが依然として紐付けられる

• 2 つのプロファイルが 1 つの IP を共有している — 各プロファイルに固有のセッションサフィックスまたは専用のスタティック IP があるか確認しましょう。
• タイムゾーン/言語が IP から導出されていない — フィンガープリントはドイツと言っているのに、IP はテキサスと言っている。
• 一度でも実際のブラウザから同じアカウントにログインした。その紐付けは決して消えません。

ダイナミックプロキシでセッション途中に IP が変わる

• スティッキーセッションには TTL があります。ワークフローがそれより長く実行される場合は、同じセッション ID を再利用するか（IP がまだ正常なら維持されます）、そのプロファイルをスタティック IP に切り替えましょう。

まとめ

どちらのブラウザもプロキシ設定を簡単にしてくれます：ホスト、ポート、ユーザー名（プロファイルごとに固有のセッションサフィックス付き）、パスワードを貼り付け、チェックを押し、ブラウザにタイムゾーンと WebRTC を IP に合わせさせるだけです。実際にアカウントを生き残らせるルールは退屈で絶対的です：プロファイルごとに 1 IP、SNS プラットフォームには住宅 IP のみ、タイムゾーンは常に IP から導出、そして初回ログイン前に漏洩を検証する。