トラブルシューティング
何かうまく動作していませんか?ほとんどの問題は以下の8つのパターンのいずれかに当てはまります。該当する症状を見つけ、診断を確認し、対処を適用してください。
ゲートウェイでの接続拒否またはタイムアウト
Section titled “ゲートウェイでの接続拒否またはタイムアウト”症状: p.shifter.io:443 に接続しようとすると、クライアントが「connection refused」「connection timed out」「no route to host」を報告する。
診断:
- 新しいゲートウェイ
p.shifter.io:443を指定していることを確認してください。旧プランではapollo.p.shifter.io:<port>のようなポートごとのサブドメインを使用します。 - 送信元のIPが、アウトバウンドの443をブロックするファイアウォールの背後にないことを確認してください。
- 生の接続性をテストします:
nc -vz p.shifter.io 443
対処: 生の接続性は正常だがプロキシが失敗する場合、問題は認証です。下記の407のセクションを参照してください。生の接続性自体が失敗する場合は、送信ファイアウォールのルールを確認し、別のネットワークから再試行してください。
HTTP 407 Proxy Authentication Required
Section titled “HTTP 407 Proxy Authentication Required”症状: すべてのリクエストが 407 Proxy Authentication Required を返す。
診断:
- 認証情報の誤り: ユーザー名またはパスワードの入力ミス。
- 不明なフラグ: 拡張ユーザー名内の国コード、都市スラッグ、またはセッション文字列の形式が不正。
- パスワードの再生成: パネルでのローテーション後、古いパスワードが無効になっている。 対処:
- まずすべてのフラグを外し、素のユーザー名とパスワードだけで再試行してください。これで動作する場合は、フラグを1つずつ追加していきます。
- shifter.io/panel の Residential Proxies でパスワードを確認してください。
- 最近パスワードをローテーションした場合は、新しい値をすべてのクライアントに反映してください。
レジデンシャルIPからの応答が遅い
Section titled “レジデンシャルIPからの応答が遅い”症状: リクエストに5〜10秒以上かかる。以前は速かったIPが遅くなった。
診断: レジデンシャルIPは実際のISP回線から提供されています。ある程度のレイテンシの変動は正常です。持続的な遅さは通常、次のいずれかが原因です:
- そのIPのエンドユーザーが回線を大量に使用している(Netflix、大容量アップロードなど)。
- ターゲットサイトがそのIPをスロットリングしている。
- プールのフィルタが狭すぎて、滞留しているIPを取得してしまっている。
対処:
- よりアグレッシブにローテーションする(スティッキーセッションを外す、または
ttlを短くする)。 - フィルタを広げる(都市指定を外し、国だけを残す)。
- ISPプロキシの場合: Managing IPs → Replace を使用して、遅いIPを新しいものに交換する。
IPのジオロケーションがターゲットと一致しない
Section titled “IPのジオロケーションがターゲットと一致しない”症状: country-us-city-new_york をリクエストしたのに、ターゲットサイトは別の場所だと判断している。
診断:
- レジデンシャルIPは、サードパーティのデータベース(MaxMind、IP2Location)によってジオロケーションが特定されます。これらのデータベースは、ターゲットサイト自身のジオロケーションソースと必ずしも一致しません。
- モバイルキャリアのIPや新規割り当てのISPレンジは、数週間にわたって誤分類されることがあります。
対処:
- リクエストを再試行してください。Shifterはリクエストごと(またはスティッキーセッションごと)に新しいIPを割り当てるため、次のIPはターゲットのデータベース上でより正確なジオロケーションを持っている可能性があります。
- 特定のターゲットに対して確実な地域指定が必要な場合は、ターゲットのURLと希望する場所を記載してサポートにお問い合わせください。そのターゲットに対してIPを事前に検証できます。
HTTPSエラー、SSL/TLSの失敗
Section titled “HTTPSエラー、SSL/TLSの失敗”症状: SSL handshake failed、certificate verify failed、または tls: bad record MAC。
診断:
- ゲートウェイの暗号スイートを拒否する古いOpenSSLまたはNodeのバージョンを使用している。
- 企業プロキシの信頼チェーンが壊れている。
対処:
- クライアントのTLSライブラリを更新してください。Node 18以上、Python requests 2.28以上、curl 7.80以上であれば問題ないことが確認されています。
- 環境が厳格なホスト指定を必要とする場合、チェーンの問題を回避するためにゲートウェイの証明書をピン留めしてください。
- デバッグ目的のみ: curlの
--proxy-insecureはプロキシ側の証明書検証を無効にします。このフラグを本番環境で使用しないでください。
ターゲットサイトに依然としてブロックされる
Section titled “ターゲットサイトに依然としてブロックされる”症状: ローテーションを伴うレジデンシャルプロキシを使用していても、特定のターゲットがCAPTCHA、403、または空のレスポンスボディを返す。
診断: ターゲットには、IP以外の要素でフィンガープリントを取る多層のアンチボット対策(Cloudflare、Akamai、DataDome)が導入されています。よくある兆候は以下の通りです:
- User-AgentがTLSフィンガープリントと一致しない(JA3/JA4の不一致)。
- ヘッダーが実際のブラウザとは異なる順序で送信されている。
- ブラウザAPI(WebDriver検出、navigator.webdriverフラグ)が自動化を露呈している。
- IPのローテーションがターゲットのセッションモデルに対してアグレッシブすぎる。
対処:
- 生のプロキシから、ステルスモードとCAPTCHA解決機能を備えたWeb Scraping APIに切り替えてください。
- または、ターゲットのURLを記載してチケットを開いてください。多くのケースは弊社側で調整可能です。
Web Scraping APIが509 Bandwidth Limit Exceededを返す
Section titled “Web Scraping APIが509 Bandwidth Limit Exceededを返す”症状: プランのクレジットが残っているにもかかわらず、Scraping APIが 509 を返す。
診断: 509 はプランのクォータが使い切られたことを意味します。ダッシュボード上でまだクレジットが残っている場合は、以下を確認してください:
- 正しいAPIキーを使用しているか(古いプランのものではないか)。
- 超過分をpay-as-you-goに変換したい場合は、Extra Trafficが有効になっているか。
対処:
- Web Scraping API → API Keys で、キーが現在のアクティブなプランと一致しているか確認してください。
- Billing → Extra Traffic を有効にして、超過分を自動的にクレジット単価の課金に変換してください。
- 頻繁にクレジットを使い切ってしまう場合は、プランをアップグレードしてください。
支払いが失敗した、またはサブスクリプションが有効化されない
Section titled “支払いが失敗した、またはサブスクリプションが有効化されない”症状: 支払いを済ませたのに、プランが非アクティブと表示される、または更新が静かに失敗する。
診断:
- カード発行会社が取引をブロックした(国際的なカード非対面決済でよく見られる)。
- カードの有効期限切れ、または3DS認証が未完了。
- 暗号資産決済がまだ確認されていない(6承認が必要)。
対処:
- ご利用の銀行アプリでカードの取引履歴を確認してください。決済が拒否されていた場合は、別のカードで再試行してください。
- 暗号資産決済の場合、決済処理業者はブロックチェーン上で6承認を得た時点で決済を検知します。通常、BTC/ETHでは15〜60分程度です。
- 決済が完了しているのに30分経ってもプランが非アクティブのままの場合は、請求書IDを添えて
hi@shifter.ioまでメールしてください。