照会ページに表示されるのはどの層の IP か？
IPアドレス検索 ページを開くと、今回のリクエストがそのサービスに対して可視化している出口アドレスが表示されます。サービスが信頼できるリバースプロキシを使用している場合、通常は自身の設定に従って転送されたクライアントアドレスを解析します。それは必ずしもコンピューターのネットワークカードのアドレスと等しいとは限りません。家庭の IPv4 ネットワークは通常、ネットワークアドレス変換（NAT）を経由しており、上流にさらに別の NAT、プロキシ、VPN が存在する可能性もあります。「端末アドレス」「ルーターの WAN アドレス」「ウェブページの観測値」をそれぞれ記録し、それらをまとめて自分のパブリック IP と呼ぶべきではありません。
プロキシや VPN がウェブの出口を変えるかどうかは、具体的なルーティングとトラフィック振り分けルールに依存します。ブラウザープロキシはウェブリクエストのみを転送する場合があり、システム VPN も企業内網セグメントのみを扱う場合があります。フルトンネル構成の場合にのみ、該当するインターネットトラフィックが VPN ゲートウェイへ送られます。したがって、同じデバイスでもアプリケーションごとに、また IPv4 と IPv6 の接続で異なる出口を使う可能性があります。ウェブページの照会だけでは、アドレスが誰によって割り当てられたか、専有かどうか、デバイスが VPN を使用しているかを判断できず、その時点で実際に有効なネットワーク構成と合わせて判断する必要があります。
プライベートまたは共有アドレスは通常、ローカルネットワークカード、ONU、またはルーターの WAN ステータスで確認します。通常の公共インターネット照会では、RFC 1918 や RFC 6598 のアドレスをグローバルにルーティング可能なクライアント出口として扱うべきではありません。ページにそのような値が表示された場合は、まずローカル情報か転送設定の問題かを確認してください。アドレスがパブリックかどうかとレピュテーションは別問題です。ルーティング可能なアドレスには悪用履歴がある場合があり、プライベートアドレスは公共のレピュテーション比較に直接参加できません。詳細は IPレピュテーションの確認方法：リスクスコアとブロックリスト を参照してください。
デバイス、ルーター、事業者：4 層のアドレス関係
まず 4 つの位置でアドレスを理解します。第 1 層は端末が LAN で使用するアドレスで、例として 192.168.50.8 があります。第 2 層は家庭用ルーターの WAN インターフェースで、パブリックアドレスを取得する場合もあれば、上流の ONU から割り当てられたプライベートアドレスを取得する場合もあります。第 3 層は事業者ネットワークで、CGNAT 展開ではユーザー側アドレスが事業者の変換を経てパブリックアドレスで外部と通信し、ユーザー側は 100.64.0.0/10 を使用する可能性があります。第 4 層は対象サービスが観測するリクエスト元です。プロキシを経由する場合、対象が見るのはプロキシの出口です。
以下は、明確に模式としてマークされた家庭の二重 NAT の事例です。あるユーザーの家庭では、ONU が事業者によってルーターモードに設定されており、ONU の LAN アドレスは 192.168.1.1 で、事業者からWANインターフェースにグローバルIPアドレス203.0.113.10（説明用のアドレスであり、実際のユーザーのアドレスではありません）が割り当てられているとします。ユーザーはさらに無線ルーターを接続し、そのルーターの WAN 口は ONU から 192.168.1.100 を取得し、LAN アドレスは 192.168.50.1 です。ユーザーのスマートフォンが取得したアドレスは 192.168.50.8 です。スマートフォンが IP 照会サイトにアクセスすると、パケットはまず無線ルーターによって送信元アドレスが 192.168.1.100 に変更され、次に ONU によって 203.0.113.10 に変更され、最終的にサーバーが見るのは 203.0.113.10 です。ユーザーのスマートフォンがローカルで見る LAN IP は 192.168.50.8、ルーターの管理画面で見る WAN IP は 192.168.1.100 で、どちらもパブリックアドレスではありませんが、最終的な出口はパブリックアドレスです。この事例はアドレス変換の順序を説明するためのものであり、実際のユーザー環境を表すものではありません。
ルーターの WAN が 100.64.0.2 で、ウェブの出口が別のグローバルにルーティング可能な IPv4 である場合、それは上流のアドレス変換と一致しますが、具体的なアーキテクチャは事業者の説明と合わせて確認する必要があります。WAN が 192.168.1.2 の場合、ONU のルーターモード、2 台目のルーター、または企業の上流ゲートウェイの可能性があります。この数値自体ではどのデバイスが NAT を行ったかはわかりません。トポロジーと各インターフェースの役割を記録することが、単一のアドレスを切り取るよりもトラブルシューティングに役立ちます。
プライベートアドレスと共有アドレス空間の正確な識別
RFC 1918 は 3 つのプライベート IPv4 範囲を定義しています。10.0.0.0/8、つまり 10.0.0.0 から 10.255.255.255、172.16.0.0/12、つまり 172.16.0.0 から 172.31.255.255、192.168.0.0/16、つまり 192.168.0.0 から 192.168.255.255 です。10 で始まるすべての IPv4 は最初の範囲に含まれますが、172 や 192 で始まるすべてのアドレスをプライベートアドレスとみなすことはできません。この 3 つの範囲に含まれないからといって自動的に公衆で使用できるわけではなく、他の特殊用途アドレス範囲も確認する必要があります。
RFC 6598 は共有アドレス空間 100.64.0.0/10 を定義しており、範囲は 100.64.0.0 から 100.127.255.255 で、サービスプロバイダーネットワーク内の特定のシナリオに使用され、グローバルにルーティング可能なアドレスではありません。ルーターの WAN がこの範囲にあることは上流の共有ネットワークの重要な手がかりですが、それだけでは事業者がどの種類の CGNAT を実装しているかを証明できません。逆に、この範囲が見られないからといって上流の NAT を排除できず、事業者の内部アドレス計画は異なる可能性があります。
判定時は必ず完全な範囲で比較し、100 で始まるすべてのアドレスを CGNAT とラベル付けしてはいけません。共有アドレスは通常、変換前の側にあり、公共の照会で見えるのは変換後のグローバルにルーティング可能な出口なので、両者は矛盾する結果ではありません。照会がプロキシを経由しているか、同じ WAN とアドレスファミリーを使用しているかを再確認してください。これらの条件を固定して初めて、アドレスの差異が説明力のある手がかりになります。最終的にプランが直接割り当てのパブリック IPv4 を提供しているかどうかは、事業者の確認と実際のネットワーク構成を基準とします。
WAN アドレスとウェブ出口の照合方法
できるだけ同じ時刻、同じ端末、同じネットワークでWeb出口のIPv4を記録し、実際にそのリクエストを運ぶルーターのWAN IPv4と照合します。再ダイヤル、Wi-Fiの切り替え、デュアルWANやプロキシによる振り分けはすべて比較に影響します。IPv6の照合方法は異なります。端末は通常独自のグローバルIPv6アドレスを持っており、ルーターのWAN IPv6と等しいことを要求すべきではありません。端末が今回使用したソースアドレス、事業者が委任したプレフィックス、想定されるルートを確認し、一時IPv6アドレスも時間とともに変化する可能性があります。
ホームネットワークでは、ステータスページと既存のトポロジーを優先して確認し、アドレスを見るためだけにデバイスを工場出荷時設定に戻す必要はありません。企業やキャンパスネットワークのユーザーは、端末の照会結果をネットワーク管理者に渡し、管理者が出口と上流の変換を照合できます。デバイスに複数のインターフェースがある場合は、インターフェース名と役割を明記し、光回線終端装置の管理アドレス、ルーターのLANアドレス、WANアドレス、VPN仮想インターフェースアドレスを区別してください。そうしないと、いくつかの正しい数値が並んでいても誤った結論に至る可能性があります。
同一のIPv4リクエストで、プロキシがなく、正しいWANを選択している条件下では、WANとWeb出口は同じです。通常は「この経路がさらにソースIPv4を変更する追加のCGNATを経由している」という推論は支持されません。ただし、アドレスが同じだからといって、静的割り当て、専有、またはインバウンド接続の許可が保証されるわけではありません。事業者のポリシーとホスト、ルーターのファイアウォールが引き続きアクセスを制限する可能性があります。インバウンド能力は、独立した外部ネットワークから自分が管理するサービスをテストし、プロトコル、ポート、失敗段階をそれぞれ記録する必要があります。
WANと出口が異なる場合、他にどのような原因がありますか？
WANアドレスとWeb出口が異なる場合、まず実際のトポロジーを考えます。光回線終端装置がルーターモードの場合、下位ルーターがそこからプライベートアドレスを取得して二重NATを形成することがあります。システムVPNもWebをリモートゲートウェイ経由でインターネットにアクセスさせる可能性があります。まず光回線終端装置の動作モード、VPNの振り分け、実際にリクエストを運ぶインターフェースを確認し、差異がどの層から来るのかを判断します。ブリッジ、ダイヤル、トンネル設定の変更は、ネットワーク要件に応じて事業者または管理者が確認するべきであり、単に2つの数値を同じにするためだけに接続方法を調整してはいけません。
ブラウザのプロキシもWeb出口を変更し、同じデバイスの他のアプリケーションは直接接続する場合があります。シークレットウィンドウは通常システムプロキシを迂回せず、すべての拡張機能を無効化することも保証しません。比較に使用するブラウザ設定では、プロキシと拡張機能の状態を確認する必要があります。企業のセキュリティゲートウェイ、リモートブラウジングサービス、マルチ出口スケジューリングも差異を生む可能性があります。管理対象デバイスでは、管理者にポリシーを確認してもらう方が、通常は企業トンネルを自分で無効化するよりも効果的です。
レイヤーごとの切り分けは順序立てて行う必要があります。まずデバイス上でVPNやプロキシが有効になっていないことを確認し、次にルーターのWANアドレスがRFC 1918またはRFC 6598の範囲内かどうかを確認します。WANがプライベートアドレスの場合、光回線終端装置がまだルーターモードの可能性があります。WANが100.64.x.xの場合、事業者がCGNATを使用している可能性があります。WANがパブリックアドレスなのにWeb出口が異なる場合、プロキシや企業ゲートウェイが存在する可能性があります。一度のスクリーンショットだけで結論を出さないでください。アドレスは動的に変化する可能性があり、プロキシソフトウェアもシステム起動時に立ち上がる場合があります。複数の時点での観察結果を記録し、ネットワークトポロジーの変化と照合することで、判断の正確性を高められます。
IPv4とIPv6は別々に検証します
IPv4とIPv6は通常並行して展開されますが、それぞれ独自のアドレス割り当て、ルーティング、ファイアウォールポリシーがあります。端末はNAT経由でIPv4を使用しながら、同時にグローバルIPv6アドレスを直接取得する場合があります。IPv6アクセスの成功は、そのIPv6経路とサービスが利用可能であることだけを示します。IPv4アクセスの失敗には、DNS、ルーティング、プロキシ、サーバー側の待ち受けなどが関わる可能性があります。CGNATは、マッピングが確立されていないIPv4インバウンド接続に特に関係しますが、すべてのIPv4アウトバウンド障害を説明するために使うべきではありません。
ブラウザー環境チェック はリクエストの出口とブラウザのネットワーク動作を観察する補助になりますが、それをもって外部ホストが能動的にあなたのIPv6サービスに接続できることを証明することはできません。インバウンド検証には、実際に待ち受けているサービス、適切なファイアウォールルール、独立した外部ネットワークからのテストが必要です。2つのプロトコルの許可ルールは異なる場合があるため、「Webページが接続できる」ことと「他者が接続できる」ことは別々に受け入れ確認すべきであり、ページにグローバルIPv6アドレスが表示されただけでインバウンドが開放されていると主張してはいけません。
トラブルシューティングでは、IPv4とIPv6の宛先、ソースアドレス、失敗段階をそれぞれ記録します。経路がプロキシやVPNの想定と一致しないと疑う場合は、WebRTC・DNS・IPv6の漏えいテスト：結果の読み方 を参照してください。WebRTC候補はブラウザが収集できるインターフェースや出口の手がかりを反映します。DNSテストは通常、テストクエリが権威サーバーに到達したときの再帰リゾルバのソースを観察するものであり、ドメイン名を解決して得られた宛先IPをあなたの出口として扱うものではありません。IPv6を無効にすると現象を覆い隠す可能性があるため、まず具体的にどの経路が想定と異なるのかを明確にすべきです。
ポートマッピングの失敗をどう分析するか
ポートマッピングが失敗した場合、まずローカルサービスが実行中で、想定したインターフェースとポートで待ち受けていることを確認します。127.0.0.1または::1のみにバインドしている場合、外部デバイスは直接接続できません。サービスの必要に応じて特定の内部インターフェースにバインドし、ホストファイアウォールと組み合わせてアクセスを制限できます。サービスをすべてのインターフェースで待ち受けるように変更することは唯一の方法ではなく、露出範囲を広げる可能性もあります。まずLAN内の別のデバイスからアプリケーションの応答を検証し、その後ルーターと上流ネットワークを層ごとに調べます。
ローカルの待ち受けとホストファイアウォールが正常なら、次にルーターのポート転送ルールを確認します。よくある誤りには、誤った内部IPへの転送、内部ポートと外部ポートの不一致、または実際のサービスがUDPを使用しているのにプロトコルをTCPに選んでしまった場合などがあります。一部のルーターでは、ファイアウォールでそのポートを個別に許可し、再起動してルールを有効にする必要があります。このとき、LAN内の別のマシンからサービスに到達できるかテストして、ルーター設定の問題を切り分けることができます。
ルーター設定が正しいのにインバウンドできない場合は、WAN IPv4とWeb出口を比較し、上流NATと事業者ポリシーを確認します。TCP接続テスト は、ツールが許可するパブリックな宛先とポート範囲内で外部観測を提供できます。入力がツールのポリシーで拒否された場合、それはターゲット接続失敗の証拠にはなりません。TCPテストはUDPサービスの検証の代わりにもなりません。外部テストの失敗は元の理由を保持し、すべてをCGNATと総称してはいけません。
外部テストでポートが到達不能と表示される場合、事業者が80、25、445などのよく使われるインバウンドポートをブロックしていないかも考慮する必要があります。一部の事業者は、ユーザーがパブリックIPや特定のポートの開放を申請しない限り、すべてのインバウンド接続をデフォルトでブロックします。この場合は、ローカル設定を繰り返し変更するのではなく、事業者に問い合わせてポリシーを確認すべきです。トラブルシューティングの順序は、ローカル待ち受け、ホストファイアウォール、ルーター転送、上流NAT、事業者制限と整理できます。各ステップで1つの変数だけを変更することで、問題の所在を正確に判断できます。
共有出口がCAPTCHAとIPレピュテーションに与える影響
共有出口IPを使用する場合、他のユーザーの行動がそのアドレスの評判に影響を与え、より多くのCAPTCHAやアクセス制限を引き起こす可能性があります。アドレスレベルの観測と具体的な使用者を区別する必要があります。アドレスレベルの観測は、あるIPが過去に自動リクエストや異常なトラフィックを示したことしか説明できず、誰が送信したのかを特定することはできず、現在の使用者が悪意を持っていることを証明することもできません。通信事業者のCGNATでは、数百以上のユーザーが同じIPv4アドレスを共有する可能性があり、誰か一人の異常がウェブサイトによってそのアドレスに記録されることがあります。
Googleの異常なトラフィックのヘルプでは、共有ネットワークやVPN内の他のユーザーによる自動クエリが異常なトラフィックの表示を引き起こす可能性があると説明されています。これは考えられる原因であり、その表示からどのユーザーやどのプログラムがリクエストを送信したかを特定できるわけではなく、その出口が特定の公開ブラックリストに載ったと断定することもできません。具体的なエラーと発生時刻を記録し、IPのブロックリスト登録と繰り返すCAPTCHAの対処法に従って、ネットワーク、ブラウザ、対象ウェブサイトのルールをそれぞれ確認してください。
共有IP自体は安全でないことを意味せず、ユーザーが悪意を持っていることも意味しません。多くの組織がIPv4アドレスを節約するためにCGNATを使用しており、これは通常のネットワークエンジニアリングの実践です。セキュリティ評価は、共有アドレスではなく、具体的なトラフィックとセッションに基づくべきです。CAPTCHAの問題でウェブサイトや通信事業者に連絡する場合、自分が共有出口環境にいることを説明し、観測可能なアクセス時間と行動の証拠を提供することができます。IP全体の「ホワイト化」を要求するのは避けてください。ホワイト化は実際の異常を隠す可能性があるからです。
ウェブサイト運営者にとって、単一のIPの評判だけに依存した判定は誤検出を招きやすいです。より合理的なアプローチは、ユーザーエージェント、TLSフィンガープリント、行動パターンなど複数のシグナルを組み合わせ、共有出口ユーザーに対してメールやSMSの確認コードなどの追加の検証方法を提供することです。一般ユーザーがCAPTCHAの増加に遭遇した場合、ネットワーク環境を変更するか、ウェブサイトに出口IPレンジとアクセス時間帯をフィードバックすることができますが、アクセス制御を迂回するツールは使用しないでください。
通信事業者へのチケットには何を書くべきか
通信事業者にチケットを提出する際、情報が完全であればあるほど処理が速くなります。正確なタイムゾーンと時刻、例えばUTC+8での具体的な日付と時間帯を提供し、事業者がログを照合できるようにする必要があります。同時にルーターのWANインターフェースに表示されているIPアドレスを記載し、ルーターのWANがパブリックアドレスでない場合はその旨を正直に記入してください。外部から観測される出口IPは照会サイトで取得でき、両者を並べることで中間NATの有無を迅速に判断できます。
IPv4とIPv6を同時に使用している場合は、それぞれ明記する必要があります。多くのモバイルネットワークや家庭用ブロードバンドではIPv6が有効になっていますが、IPv4は依然としてCGNATを経由する可能性があります。問題を説明する際に「アクセスできない」とだけ言うのではなく、必要なインバウンドプロトコルを明示してください。例えばHTTPSにはTCP 443ポート、WireGuardにはUDP 51820ポートが必要です。現在のトポロジー、例えば光回線終端装置がブリッジモードかルーターモードか、ルーターのブランドと型番、セカンダリルーターを経由しているかどうかも説明してください。
チケットで通信事業者にIPをブラックリストから「ホワイト化」するよう要求すべきではありません。そのアドレスが誤ってマークされたという具体的な証拠がある場合を除きます。より適切な質問は、現在のプランがパブリックIPv4アドレスを提供するか、インバウンド接続を許可するか、IPv4が利用できない場合にIPv6インバウンドを提供するか、というものです。これらの質問は評判ではなくネットワーク能力に直接関係します。完全なトラフィック記録やアクセス資格情報などの機密ログは積極的に提供する必要はありませんが、事業者がさらなる調査を必要とする場合は、最小限の原則に従って匿名化したログを提供できます。
通信事業者が証拠の提供を求める場合、タイムラインを整理できます。いつポートマッピングを設定したか、どの外部ネットワークからテストしたか、どのテストツールを使用したか、どのような結果が得られたか。これらの証拠は変更せず、スクリーンショットや出力を編集しないでください。チケットのフォローアップでは、各コミュニケーションの時刻、カスタマーサービス番号、結論を記録し、確認可能な記録を作成します。期待する解決方法と次のステップの時間枠を明確に書くことも処理効率を高めます。
家庭ユーザーと開発者はそれぞれどう選ぶか
家庭ユーザーが自分で管理するデバイスにリモートアクセスする必要がある場合、まずプランがパブリックIPv4またはIPv6インバウンドをサポートしているかを確認し、適切なソリューションを選択できます。直接のインバウンド能力がない場合は、認証付きのリバーストンネルやリレーサービスを評価し、アクセス制御、メンテナンス方法、費用、可用性を確認し、所属ネットワークの管理規則を遵守してください。このようなソリューションが必要かどうかはビジネス目標に依存し、「パブリックIPv4が必須」をすべてのリモートアクセスの前提とする必要はありません。
パブリックIPとポート到達性について、家庭ユーザーにはよくある誤解があります。ルーターのWANアドレスがパブリックアドレスであれば、すべてのポートがインターネットからアクセスできると考えることです。実際には、多くの家庭用ブロードバンドはパブリックIPv4が割り当てられていても、通信事業者のエッジデバイスで一般的なサービスポートをブロックします。また、動的パブリックIPは変化する可能性があり、リモートアクセスには動的DNSも併用する必要があります。一時的なアクセスのためだけなら、ベンダー提供のリモート管理や認可されたリレーサービスを使用する方が安全です。
開発者がインターネットサービスの連携テストを行う際、ローカルマシンからの外部アクセス成功をインターネットインバウンドの検証とみなしてはいけません。ローカルマシンがNATやファイアウォールを介してアウトバウンドアクセスに成功したことは、アウトバウンド経路が通っていることを示すだけで、外部がローカルマシンに能動的に接続できることを証明するものではありません。例えば、Webサービスがlocalhostで実行されており、curlで外部APIにアクセスして成功しても、外部ユーザーがそのWebサービスにアクセスできることを証明できません。別のネットワークにある別のマシンから、または外部TCP検査ツールを使用して能動的な接続テストを行う必要があります。
開発者はコンテナ、仮想マシン、ホスト間のポート公開も確認する必要があります。コンテナ内のサービスが正常でも、ホストが期待するインターフェースでそのポートを開放しているとは限りません。ホストのループバックアドレスでアクセスできても、LANやインターネットからアクセスできるとは限りません。最終検証では観測点とアプリケーション結果を明記する必要があります。TCPサービスでは接続の確立と期待されるインタラクションの完了が必要で、UDPサービスではプロトコルに準拠したリクエストを送信して応答を確認する必要があります。接続ハンドシェイクのないUDPから「TCPが確立された」ような結論を導いてはいけません。
よくある3つのQ&A
パブリックIPは固定されていますか？これは通信事業者とプランによって異なります。家庭用ブロードバンドは通常動的アドレスを使用し、パブリックIPv4が割り当てられていても、リース期限切れ、再ダイヤル、デバイス再起動後に変更される可能性があります。企業専用線や固定IPプランでは静的アドレスが提供されますが、追加料金が必要です。IPv6アドレスは通常プレフィックス委任によって提供され、事業者のプレフィックスが変わらなければデバイスアドレスは一定期間安定することがありますが、永久に不変であることは保証されません。アドレスが固定されていると仮定せず、リモートサービスには動的DNSや定期的な設定更新が依然として必要です。
ルーターを再起動すると必ずアドレスが変わりますか？いいえ。アドレスの変化はDHCPリース時間、通信事業者のアドレスプールポリシー、認証方式によって決まります。再起動後にアドレスが変わらないこともあれば、変わることもあり、一般的な規則はありません。CGNAT環境では、再起動によって変わるのは事業者内部のマッピング関係であり、パブリック出口アドレスではない可能性があります。現在の出口が変化したかどうかを確認する必要がある場合は、再起動の前後に複数の独立した照会サービスを使用して出口IPを記録し、タイムゾーンとネットワーク環境が変わらないことに注意してください。
複数のユーザーがパブリックIPを共有しているからといって、自動的に互いにアクセスできるわけではなく、セキュリティ隔離の証明にもなりません。実際の隔離はアクセスネットワークの設定、アクセス制御、デバイスのファイアウォールに依存しており、NATを完全なセキュリティ境界として扱うことはできません。共有出口はレピュテーションの関連付けを生み、通常のユーザーも一緒にCAPTCHAや制限に遭遇する可能性がありますが、具体的な影響は対象ウェブサイトのポリシーによって異なります。接続性、アドレスのレピュテーション、デバイスのセキュリティをそれぞれ評価し、一つの「共有」ラベルで全ての問題をまとめてしまうのは避けるべきです。
再確認可能な記録を作成する
パブリックIPとポートの到達性の問題を調査する際、記録は事後検証を支えるものでなければなりません。タイムラインを作成する際は、例示的な方法を用います。例えば、ある日10:00にルーターのポート転送を設定し、10:05に外部ネットワークからTCP検証ツールでポート8443をテストして失敗、10:10にホストのファイアウォールを変更し、10:15に再テストしても依然として失敗した、といった記録は、各ステップの行動と結果を明確に示します。失敗した操作を省略しないでください。失敗も変数を除外するのに役立ちます。
毎回一つの変数だけを変更し、前後の結果を記録してください。ファイアウォールとルーターのルールを同時に調整すると、原因の特定が難しくなります。状態ページ、エラーテキスト、テスト時刻、出口の結果を保存し、外部に資料を提供する際はアカウントやトークンなどの無関係な情報を削除します。アドレスの種類、出所、観測境界を理解するには、当サイトのデータソースと評価方法をお読みください。記録の重点は、次の調査者が条件を再現できるようにすることであり、説明のつかないスクリーンショットを積み上げることではありません。
共有IPやプロキシ検出は誤判定を生む可能性があります。例えば、通常のホームネットワークが共有出口のためにVPNやプロキシとしてマークされることがあります。この場合、出口IP、クエリ時刻、検出プラットフォームを収集し、複数のプラットフォームでの判定の違いを記録すべきです。一つのブラックリストや検出サービスだけに依存しないでください。CGNATセグメントに対して不親切なプラットフォームもあります。関連する誤判定の事例と調査の方向性についてはVPNを使っていないのにプロキシ判定される原因と確認方法を参照してください。そこでは、アドレスレベルのマークと実際のプロキシ動作をどのように区別するかが説明されています。
調査記録が十分に完全であるにもかかわらず問題を解決できない場合、明確な停止条件を設定すべきです。例えば、ローカルのリスニングとファイアウォールを変更し、ルーターのルールが正しいことを確認し、2つの異なる外部ネットワークからテストしてすべて失敗し、さらにISPがインバウンド能力がないと回答した場合、次のステップはISPにパブリックアドレスを申請するか、許可されたリレーソリューションを採用することであり、推測や変更を続けることではありません。終了後、すべての記録をアーカイブし、結論を「インバウンド接続を確立できず、原因はISPのポリシーに帰する」と注記し、証拠の連鎖を添付します。
