Power Appsでの HTTP 0 応答とその他のブロックされた呼び出しのトラブルシューティング

適用対象: Power Apps、Power Automate

まとめ

この記事は、サービスに到達しない、または中間デバイスからエラーを返すPower Apps呼び出しとPower Automate呼び出しを調査するのに役立ちます。 一般的なエラーには、 0の HTTP 状態、 403、 407、 502、 503などのプロキシによって発行された状態、 (failed) または (canceled)としてマークされた要求が含まれます。 エラーがクライアント側またはネットワーク パスで発生したかどうかを判断し、適切な診断をキャプチャし、ネットワーク チームと協力して修正を行う方法について説明します。

Symptoms

Power Platform サービスが正常な応答を返す前に、コネクタまたは Web 要求が失敗します。 多くの場合、エラーは断続的であり、次のいずれかの条件が発生します。

  • Power Apps 0 ツール、フロー実行履歴、またはブラウザー開発者ツールのの HTTP 状態コード。 通常、応答には本文もヘッダーも、意味のあるエラーメッセージも含まれません。

  • ブラウザー開発者ツールの [(failed)] タブに(canceled)またはの状態が表示されている要求。

  • Power Platform ではなく、中間デバイス (Zscaler、Netskope、企業プロキシ ブロック ページなど) によって返される HTTP 状態。 例えば次が挙げられます。

    • 403 Forbidden
    • 407 Proxy Authentication Required
    • 502 Bad Gateway
    • 503 Service Unavailable

  • fetchまたはXMLHttpRequestを使用し、status: 0または一般的なネットワーク エラーを受け取るカスタム コード。

これらの現象はすべて共通のルート パターンを共有します。要求は、サービス自体によって処理および拒否されるのではなく、クライアント デバイスと Power Platform サービスの間でブロックまたは変更されます。

原因

0の HTTP 状態は、サーバーからの実際の応答ではありません。 これは、ブラウザーまたはクライアントがリモート エンドポイントから応答を受信しなかったことを意味します。 通常、この状態は、要求がラウンド トリップを完了する前にブロック、削除、または終了されたために発生します。 403や407などのプロキシによって発行された状態は、同様のことを意味します。中間デバイスが要求をインターセプトし、Power Platform に要求を転送する代わりに独自の応答を返しました。

一般的な原因には、次のようなものがあります。

  • 一時的なネットワーク障害または不安定なデバイス接続 (Wi-Fi の切断、VPN 切断、携帯ネットワークのハンドオフなど)
  • 接続の終了、スロットル、またはサイレント ドロップを行う企業プロキシ、ファイアウォール、または SSL/TLS 検査デバイス
  • CORS ヘッダーの書き換えまたは削除 (たとえば、Access-Control-Allow-Originを制限値に変更する) と、ネットワーク呼び出しが完了する前にブラウザー側のエラーが発生するネットワーク アプライアンス
  • Power Platform サービス エンドポイントをブロックする DNS 解決エラーまたは DNS ベースのフィルター処理
  • Power Platform のトラフィックを傍受し、それをブロックしたり、書き換えたり、カスタム エラー ページを返したりするセキュア Web ゲートウェイまたはゼロトラスト製品 (Zscaler や Netskope など)
  • 送信前に要求をキャンセルするブラウザー拡張機能 (広告ブロック、プライバシー ツール) またはローカルウイルス対策ソフトウェア
  • プロキシされたトラフィックをローカル リソース アクセスとして扱い、要求をブロックするブラウザーのローカル ネットワーク保護
  • ユーザーが移動したり、タブを閉じたり、要求が完了する前にデバイスをスリープ状態にしたりする

Note

これらのエラーは、Power Platform サービスではなく、クライアント側またはネットワーク パス内で発生します。 通常、解決するには、要求がブロックされている、リダイレクトされる、または接続が失われる理由を特定するために、ネットワーク管理者との調整が必要です。

問題の原因を特定する

要求がネットワークに到達したことを確認する

ブラウザーの開発者ツールを使用して、失敗した呼び出しを調べます。

  1. ブラウザーで F12 キーを押して開発者ツールを開き、[ ネットワーク ] タブを選択します。

  2. アプリまたはフローで問題を再現します。

  3. 失敗した要求を見つけます。 次のインジケーターの 1 つ以上に一致する応答を探します。

    • 状態 0、 (failed)、または (canceled)
    • Power Platform の応答に似ていない 403、407、または 502 の応答

  4. 要求を選択し、[ ヘッダー] セクションを確認します。 [リモート アドレス] フィールドを詳しく調べます。 また、要求がサービスではなくプロキシまたはセキュリティ アプライアンスから送信されたことを示す応答本文を確認します。

"4xx" 応答と "5xx" 応答の場合は、 x-ms-correlation-id や x-ms-request-id (GUID 値を含む) などの Power Platform サービス マーカーの応答ヘッダーを調べます。

  • 少なくとも 1 つの有効な x-ms-* 要求/関連付けヘッダーが存在する場合、要求はサービスに到達した可能性が高く、そこで拒否されました。
  • これらのヘッダーが見つからない場合、応答がプロキシまたはゲートウェイ ページに似ている場合は、中間ネットワーク デバイスによって応答が生成された可能性があります。

Microsoft サポートを使用する場合は、キャプチャした x-ms-correlation-id または x-ms-request-id 値を含めます。 これらの識別子は、要求をサービス テレメトリと関連付けるのに役立ちます。

[リモート アドレス] フィールドは、最も明確なシグナルの 1 つです。

  • フィールドに IP アドレスとポート ( 192.0.2.10:443 など) が表示されている場合、要求はリモート サーバーに到達しました。 その後、TLS、CORS、またはサービス側の問題が発生する可能性が高くなります。

  • IP アドレスのないポート (:443や:80など) のみがフィールドに表示される場合、デバイスまたはローカル ネットワークを離れる前に接続がブロック、インターセプト、またはショートサーキットされました。 これは、プロキシ、ファイアウォール、DNS フィルター、またはセキュリティ エージェント (Zscaler など) が要求を転送するのではなく、ローカルで処理することを強くお勧めします。 プロキシが発行した 403 または 407 応答と一緒に同じパターンが表示されることがよくあります。

    ブラウザー開発者ツールで失敗したネットワーク要求のスクリーンショット。ポートと IP アドレスを含まないリモート アドレス フィールドが表示されています。

セッションの HAR ファイル をキャプチャして、ネットワーク チームと共有できるようにします。

デバイスと接続の問題を除外する

ネットワーク チームに参加する前に、基本的なデバイスと接続の問題を除外します。

  • 別のネットワーク (モバイル ホットスポットなど) 上の問題を再現して、問題がユーザー、デバイス、または企業ネットワークに従うかどうかを確認します。
  • 別のブラウザーを試すか、拡張機能を無効にして InPrivate ウィンドウまたは Incognito ウィンドウを使用します。
  • デバイスに安定した接続があり、電源管理のために Wi-Fi が中断されていないことを確認します。
  • 同じネットワーク上の別のデバイスからテストして、デバイス固有の問題を特定します。

代替ネットワークで呼び出しが成功したが、企業ネットワークで失敗した場合、問題はほぼ確実に企業ネットワーク パスにあります。

障害が特定のリージョンのユーザーにのみ影響する場合は、中間デバイスによる DNS 応答サイズのフィルター処理も検討してください。 一部の Power Platform ホスト名チェーンでは、DNS の回答が大きくなります (たとえば、CNAME の拡張と地理的ルーティングが原因)。 RFC 1035 からの古い DNS サイズの前提条件を適用するデバイスは、RFC 6891 で有効な応答をブロックできます。 その結果、リージョン固有のアプリの読み込みまたはコネクタのエラーが発生します。

ネットワーク管理者と連携する

証拠は企業ネットワークを指している可能性があります。 たとえば、リモート IP が不足しているか、企業ネットワークでのみ障害が発生したり、他のユーザーが影響を受けたりすることがあります。 このような場合は、ネットワーク管理者に問い合わせてください。 問い合わせる際に、次の情報を提供します。

  • 前にキャプチャした HAR ファイル
  • 失敗した要求の正確な URL (ホスト名とパス)
  • 問題が発生したおおよその時間、ユーザー、デバイス

ネットワーク チームに次の条件を確認するよう依頼します。

  • 必要なすべての Power Platform エンドポイントは、プロキシ、ファイアウォール、SSL 検査デバイスを介してエンド ツー エンドで許可されます。 ホスト名と IP 範囲の権限のある一覧は、 Power Platform の URL と IP アドレス範囲にあります。
  • DNS は Power Platform エンドポイントを正しく解決します。
  • 許可リストルールは、動的なホスト名とサブドメインを対象とします。 Power Platform 要求では、単一の固定ホストではなく、サービス ドメインの下で環境固有の長いホスト名を使用できます。 以前に観察されたサブドメインのみを許可するルールは、アプリ ロジックが変更されていない場合でも、次のルーティング変更で失敗する可能性があります。
  • Power Platform によって返される CORS ヘッダーは、エンド ツー エンドで保持されます。 ヘッダーの書き換えまたは削除により、エンドポイントの許可リストが正しい場合でも、ブラウザー レベルのエラー (HTTP 状態 0を含む) が発生する可能性があります。
  • 検査デバイスでは、より大きな DNS 応答と EDNS の動作がサポートされます。 この状態は、障害がリージョンまたはオフィスの場所によって集中している場合に特に重要です。
  • Web ゲートウェイ (Zscaler、Netskope など) 内のすべての許可リスト Power Platform ホスト名をセキュリティで保護し、SSL/TLS 検査から保護します。 SSL 検査は、HTTP 0 応答や予期しない 403 または 502 エラーの根本原因としてよくある原因です。 検査デバイスは、コネクタ ランタイムが依存する有効期間の長い接続またはチャンク接続を中断する可能性があります。 また、ポリシーの一致が発生した場合は、独自のブロック ページを返すこともできます。

ブラウザーのローカル ネットワーク保護が疑われる場合は、関連するブラウザーのガイダンスを確認してください。 Chromium については、「 プライベート ネットワーク アクセス: プレフライトの概要」を参照してください。

追加の診断を収集する

ネットワーク チームが構成を検証した後も問題が解決しない場合:

  • 失敗した呼び出し中にネットワーク トレース (たとえば、Wireshark または Windows の pktmon) をキャプチャします。
  • Power Apps Live Monitor ツールを使用して、エラーが要求間で一貫しているか、特定のコネクタに限定されているかを確認します。
  • HAR エントリで、 Viaなどのプロキシ識別ヘッダーを確認します。
  • 現行のHTTP/2が想定される状況でのHTTP/1.1応答など、プロトコルのダウングレードパターンを探します。 コネクタ トラフィックでは、最新の HTTP を使用する必要があります。 そのため、ダウングレードの繰り返しは、中間検査またはプロキシ フォールバックを示すことが多く、信頼性とパフォーマンスに影響を与える可能性があります。
  • ブラウザーのローカル ネットワーク アクセス プロンプトが表示された場合、またはアクセスが拒否されたと表示された場合は、ネットワーク チームの詳細を収集します。 ルーティング不可能なアドレス範囲またはプライベート アドレス範囲を使用する一部のプロキシ設計では、ローカル ネットワーク保護をトリガーし、要求をブロックできます。
  • エラーが特定の時刻、特定のユーザー、特定の地理的な場所、または特定のコネクタに関連付けられるかどうかに注意してください。 多くの場合、この情報は、ネットワーク チームが責任を負うデバイスまたはポリシーを特定するのに役立ちます。

解決策

通常、IT チームまたはネットワーク チームはほとんどの修正を行います。 キャプチャした HAR ファイルとプロキシ ログを共有し、次の 1 つ以上の変更を適用します。

  • すべてのプロキシ、ファイアウォール、DNS フィルターを介して 、Power Platform の URL と IP アドレス範囲 を許可します。
  • Zscaler、Netskope、または同様のゲートウェイで、Power Platform ホスト名の SSL/TLS 検査をバイパスします。
  • 影響を受けるユーザーのデバイス接続 (Wi-Fi、VPN、携帯ネットワーク) を安定させます。
  • Power Platform エンドポイントへの要求をキャンセルまたは書き換えるブラウザー拡張機能またはエンドポイント セキュリティ製品を確認して再構成します。

これらの変更を行った後も問題が解決しない場合は、更新されたトレースを収集し、ネットワークチームとセキュリティ チームと一緒にトラブルシューティングを続けます。

関連するコンテンツ

サードパーティの情報に関する免責事項

この記事で説明するサード パーティ製品は、Microsoft に依存しない企業によって製造されています。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。

  • Last updated on