このページは Cloud Translation API によって翻訳されました。

400 Bad request - プレーン HTTP リクエストが HTTPS ポートに送信される

<ph type="x-smartling-placeholder"></ph> 現在、Apigee Edge のドキュメントが表示されています。
Apigee X のドキュメント。詳細

症状

クライアントアプリケーションが HTTP 400 Bad Request レスポンスと次のメッセージを受け取ります。 The plain HTTP request was sent to HTTPS port。

エラーメッセージ

クライアントアプリケーションは次のレスポンスコードを受け取ります。

HTTP/1.1 400 Bad Request

その後に、以下の HTML エラーページが表示されます。

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
</body>
</html>

考えられる原因

原因	説明	トラブルシューティングの実施対象
TLS で構成された仮想ホストへの HTTP リクエスト	クライアントが TLS で構成された仮想ホストに HTTP リクエストを送信する	Edge Public Cloud ユーザーと Edge Private Cloud ユーザー
TLS で構成されたターゲットエンドポイントへの HTTP リクエスト	ターゲットエンドポイント内の TLS 対応バックエンドサーバーに対して行われた HTTP リクエスト。	Edge Public Cloud ユーザーと Edge Private Cloud ユーザー
ターゲットサーバーの構成が正しくない	ターゲットサーバーはセキュアポート `443` で構成されていますが、SSL が有効になっていません。	Edge Public Cloud ユーザーと Edge Private Cloud ユーザー

原因: TLS 構成の仮想ホストへの HTTP リクエスト

このエラーは、クライアントが Apigee の API と前述の API に接続しようとした場合に発生します。 SSL を使用するように仮想ホストが構成され、代わりに HTTP リクエストを受信します。

診断

この問題は <ph type="x-smartling-placeholder"></ph> ノースバウンドエンドポイントと API リクエストは、接続する場合、これらのエラーメッセージは NGINX ルーターにはログに記録されません。確認できます。そのため、これらのリクエストは API Monitoring や API などのツールで取得されません。使用します。

API リクエストを検証し、有効なホストエイリアスに HTTP リクエストを発行していないか、セキュアポート 443 でのみリクエストを受け入れるように構成されています。もしそうなら、それが問題の原因です。

正しくない API リクエストの例:
```
curl http://org-test.apigee.net:443/400-demo
```
```
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>server</center>
</body>
</html>
```
上記のサンプルリクエストでは、HTTP リクエストがホストエイリアスに送信されることに注意してください。セキュアポート 443 の myorg-test.apigee.net。これが Pod の 400 Bad Request エラー。

解決策

クライアントが HTTPS ではなく HTTP を使用しているかどうかを確認し、正しいリクエストを下に示します。

API リクエストの例:

curl https://org-test.apigee.net:443/400-demo

または

curl https://org-test.apigee.net/400-demo

< HTTP/1.1 200 OK
< Date: Thu, 25 Feb 2021 13:01:43 GMT
< Content-Type: text/xml;charset=UTF-8
< Content-Length: 403
< Connection: keep-alive
< Server: gunicorn/19.9.0
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Credentials: true

</ph> 注: 標準のセキュアポート 443 で HTTPS プロトコルを使用する場合、上記のサンプルリクエストに示されているように、ポート番号は不要です。

原因: TLS 構成のターゲットエンドポイントへの HTTP リクエスト

このエラーは、TLS 対応のバックエンドへの HTTP リクエストが正しく構成されていない場合に発生します。 API プロキシのターゲットエンドポイントに配置する必要があります。

診断

Trace ツールを使用してエラーを診断する手順は次のとおりです。

問題の API プロキシの Apigee UI で [Trace] を有効にします。
API プロキシにリクエストを送信します。
400 レスポンスコードで失敗した API リクエストを 1 つ選択します。
さまざまなフェーズを順に実施して、エラーの発生場所を特定します。
通常、バックエンドサーバーからの 400 エラーレスポンスが表示されます。つまり、400 エラーレスポンスは [Response received（応答を受信）] フェーズにターゲットサーバーから実行します。
[AX] をクリックして、リクエストが行われたターゲットエンドポイントを特定します。（Analytics Data Recorded）アイコンをクリックします。
target.urltarget.url にはプロトコル、バックエンドサーバーのホストエイリアス、ポート番号も含まれます接続に使用するポートはターゲット URL は 443 ですが、プロトコルは HTTP です。
ターゲットエンドポイントの定義を確認して、構成を理解します。
バックエンドサーバーホストがセキュアで、443 などのセキュアポートをリッスンしていることを確認します。 <URL> 要素の http としてプロトコルを使用している場合、次のようになります。それがこの問題の原因です。

ターゲットエンドポイントの構成例:
```
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <URL>http://somehost.org:443/get</URL>
    </HTTPTargetConnection>
</TargetEndpoint>
```
上の例では、HTTP プロトコルを使用していますが、使用するポートはセキュアです。ポート 443。これにより、バックエンドサーバーが 400 Bad Request とエラーメッセージ The plain HTTP request was sent to HTTPS port。

解決策

バックエンドサーバーがセキュアで TLS 対応の場合は、そのプロトコルを次に示すように、ターゲットエンドポイントの <URL> 要素内の https 次の例をご覧ください。

ターゲットエンドポイントの構成例:
```
<HTTPTargetConnection>
    <Properties/>
    <URL>https://somehost.org:443/get</URL>
</HTTPTargetConnection>
```
<ph type="x-smartling-placeholder">
</ph> 注: 標準のセキュアポート 443 で HTTPS プロトコルを使用する場合、ポート番号を含める必要はありませんこの例では、ポート番号が IP アドレスの理解しやすいことが必要です。
バックエンドサーバーが安全でない場合:
- セキュアなポート番号は指定しないでください（443 など）。
- バックエンドサーバーがリッスンする場合、ポート番号を指定する必要はありません。標準の非セキュアポート
- セキュアでない他のポートを使用している場合は、ポート番号を指定します。次に例を示します。 9080
ターゲットエンドポイントの構成例:
```
<HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org/get</URL>
</HTTPTargetConnection>

or

<HTTPTargetConnection>
    <Properties/>
    <URL>http://somehost.org:9080/get</URL>
</HTTPTargetConnection>
```

原因: ターゲットサーバーの構成が正しくない

ターゲットサーバーが 443 などのセキュアポートで構成され、有効になっていない場合 SSL の場合、Apigee Edge の Message Processor は安全な HTTP リクエストまたはこの問題の原因となっている TLS 構成のターゲットサーバー。

診断

Trace ツールを使用してエラーを診断する手順は次のとおりです。

問題の API プロキシの Apigee UI で [Trace] を有効にします。
API プロキシにリクエストを送信します。
400 レスポンスコードで失敗した API リクエストを 1 つ選択します。
さまざまなフェーズを順に実施して、エラーの発生場所を特定します。
通常、バックエンドサーバーからの 400 エラーレスポンスが表示されます。つまり、400 エラーレスポンスは、レスポンス受信済みフェーズに表示されています。ターゲットサーバーから実行します。
[AX] をクリックして、リクエストが行われたターゲットエンドポイントを特定します。（Analytics Data Recorded）アイコンをクリックします。
ターゲットエンドポイント名を表す target.name をメモします。

上のトレースファイルの例では、target.name は default となっています。これは、デフォルトに設定されます。

ターゲットエンドポイントの定義を確認して、構成を理解します。

ターゲットエンドポイントの構成例:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<TargetEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request/>
        <Response/>
    </PreFlow>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <Flows/>
    <HTTPTargetConnection>
        <Properties/>
        <LoadBalancer>
        <Server name="faulty-target"/>
        </LoadBalancer>
    </HTTPTargetConnection>
</TargetEndpoint>

上記のターゲットエンドポイント構成の例は、ターゲットサーバーを使用していることを示しています。 faulty-target という名前で作成されます。

ターゲットサーバー名を確認したら、次のいずれかの方法でターゲットサーバーの構成を確認します。
- Edge UI
- Management API

Edge UI

[Apigee Edge] >管理 >環境 >ターゲットサーバーをご覧ください。
API プロキシから識別された特定のターゲットサーバーを選択して、編集。
ターゲットサーバーで指定されたポートと SSL 情報を確認します。
ターゲットサーバーがセキュアなポート（443 など）で構成されている場合: SSL が有効になっていない場合、それがこの問題の原因です。

上のスクリーンショットからわかるように、使用されるポートは 443 ですが、SSL ではありません。有効にする必要があります。これにより、Apigee Edge のメッセージ HTTP リクエストをセキュアなポート 443 に送信するプロセッサ。したがって、エラー 400 Bad Request とメッセージ The plain HTTP request was sent to HTTPS port。

Management API

次のコマンドを実行します。 <ph type="x-smartling-placeholder"></ph> Get target server API で、特定のターゲットサーバー構成の詳細を取得します。次のように指定します。

Public Cloud ユーザー:

curl -v 'https://api.enterprise.apigee.com/v1/organizations/ORG_NAME/environments/ENV_NAME>/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"

Private Cloud ユーザー:

curl -v 'http://MANAGEMENT_IP:8080/v1/organizations/ORG_NAME/environments/ENV_NAME/targetservers/TARGET_SERVER_NAME' \
-H "Content-Type:application/xml" \
-H "Authorization:Bearer $TOKEN"

ターゲットサーバーで指定されたポートと SSL 情報を確認します。
ターゲットサーバーがセキュアなポート（443 など）で構成されている場合、 SSLInfo セクションが定義されていないか、有効になっていない場合は、できます。

ターゲットサーバーの構成例:
```
{
  "host" : "somehost.org",
  "isEnabled" : true,
  "name" : "faulty-target",
  "port" : 443
}
```
上記のサンプル出力では、ターゲット接続に使用されているポートが 443。ただし、SSLInfo 構成ブロックはありません。

これにより、Apigee Edge の Message Processor は HTTP リクエストをセキュアポートに送信します。 443。したがって、次のメッセージを含むエラー 400 Bad Request が表示されます。 The plain HTTP request was sent to HTTPS port。

解決策

ターゲットサーバーがセキュアの場合、または TLS 構成されている場合は、特定のサーバーに対して SSL を有効にする必要があります。ターゲットサーバーにありません。

これは、次のいずれかのオプションを使用して行うことができます。

Edge UI
Management API

Edge UI

Edge UI >管理 >環境 >ターゲットサーバーをご覧ください。
特定のターゲットサーバーを選択し、 [編集] をクリックします。
ターゲットサーバーがセキュアで、443 などのポートを使用している場合は、次の方法で SSL を有効にします。 SSL オプションの横にあるチェックボックスを選択してオンにします
Truststore、Truststore、Truststoreを構成します。（必要な場合のみ）

Management API

次の説明にあるように、管理 API を使用してターゲットサーバーを構成します。 <ph type="x-smartling-placeholder"></ph> ターゲットサーバーの構成を更新するのドキュメントをご覧ください。

診断情報の収集が必要な場合

上記の手順でも問題が解決しない場合は、以下の情報を収集します。 Apigee Edge サポートにお問い合わせください。

Public Cloud ユーザーの場合は、次の情報を提供してください。 <ph type="x-smartling-placeholder">
- 組織名
- 環境名
- API プロキシの名前
- エラーを再現するための curl コマンドを完了する
- Trace ツールの出力（失敗したリクエストをキャプチャできた場合）
プライベートクラウド ユーザーの場合は、次の情報を提供してください。 <ph type="x-smartling-placeholder">
- 確認された完全なエラーメッセージ
- 環境名
- API プロキシバンドル
- ターゲットサーバーの定義（エンドポイントでターゲットサーバーを使用している場合）
- Trace ツールの出力（失敗したリクエストをキャプチャできた場合）

400 Bad request - プレーン HTTP リクエストが HTTPS ポートに送信される

症状

エラー メッセージ

考えられる原因

原因: TLS 構成の仮想ホストへの HTTP リクエスト

診断

解決策

原因: TLS 構成のターゲット エンドポイントへの HTTP リクエスト

診断

解決策

原因: ターゲット サーバーの構成が正しくない

診断

Edge UI

Management API

解決策

Edge UI

Management API

診断情報の収集が必要な場合

エラーメッセージ

原因: TLS 構成のターゲットエンドポイントへの HTTP リクエスト

原因: ターゲットサーバーの構成が正しくない