発行
SLB インスタンスを設定後、500 Internal Server Error、502 Bad Gateway、504 Gateway Timeout などのエラーが発生することがあります。 エラーは、インターネットサービスプロバイダー (ISP) からのブロック、異常なクライアントアクティビティによるAlibaba Cloud Securityからのブロック、SLBインスタンスの設定エラー、ヘルスチェックの失敗、またはバックエンドのElastic Compute service (ECS) インスタンス上のwebアプリケーションへのアクセスの失敗が原因で発生する可能性があります。 このトピックでは、これらのエラーの解決策について説明します。 エラーが残っている場合は、トラブルシューティング手順の情報に基づいてエラーをトラブルシューティングします。
原因
次のセクションでは、HTTP 5xxエラーの考えられる原因について説明します。
解決策
解決策
オリジンサーバーのドメイン名にICP番号がないか、またはAnti-DDoSのドメイン名にレイヤー7転送ルールが設定されていません。
オリジンサーバーのドメイン名にICP番号がない場合は、ドメイン名のICP番号を申請します。 詳細については、「ICPファイリング」をご参照ください。 ドメイン名にAnti-DDoSが設定されている場合は、ドメイン名のルールを設定します。 詳細については、「ルール」をご参照ください。
クライアントのIPアドレスがAlibaba Cloud Securityによってブロックされている
クライアントIPアドレスをIPアドレスホワイトリストに追加します。 詳細は、「IPアドレスホワイトリスト」をご参照ください。
クライアントIPアドレスがISPによってブロックされています
他のISPのクライアントに同じ問題があるかどうかを確認します。 そうでない場合、問題は特定のISPからの妨害によって引き起こされます。 ISPによってパケットがブロックされているかどうかを確認するか、チケットを起票してAlibaba Cloudに連絡してテクニカルサポートを受けることができます。 パケットがISPによってブロックされている場合は、ISPに連絡して問題を解決してください。
リクエストはバックエンドECSインスタンスのセキュリティソフトウェアによってブロックされます
100.64.0.0/10は、ヘルスチェックとリクエスト転送のためにAlibaba CloudがSLBサーバー用に予約したCIDRブロックです。 CIDRブロックはユーザーに割り当てられておらず、セキュリティ上のリスクはありません。 ECSインスタンスにセキュリティソフトウェアをインストールするか、ファイアウォールを有効にする場合、このCIDRブロックをホワイトリストに追加するか、セキュリティソフトウェアをアンインストールして、500や502エラーを防ぐことができます。 このセクションでは、例としてLinuxインスタンスのiptablesを使用します。
問題が検出されたバックエンドサーバーにログインし、次のコマンドを実行してフィルターテーブルのすべてのルールを表示します。
iptables -nL次の出力が表示された場合、バックエンドサーバーはSLBのプライベートCIDRブロックからのリクエストをブロックします。
次のコマンドを実行して、このルールを削除します。
説明iptablesを無効にできる場合は、/etc/init.d/iptables stopコマンドを実行してiptablesを無効にします。
sudo iptables -t filter -D INPUT -s 100.64.0.0/10 -j DROP次のコマンドを実行して、バックエンドサーバーがSLBのプライベートCIDRブロックからのリクエストをブロックしないことを確認します。
sudo iptables -nL
バックエンドECSインスタンスのLinuxカーネルのパラメーターが正しく設定されていない
バックエンドECSインスタンスがLinuxを使用しており、SLBインスタンスのプロトコルをHTTPからTCPに変更した場合、rp_filterパラメーターの値を変更する必要があります。 /etc/sysctl.confファイルで、次のパラメーターの値を0に設定し、sysctl -pコマンドを実行します。
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0バックエンドECSインスタンスにパフォーマンスのボトルネックがある
CPU使用率やインターネット帯域幅など、バックエンドECSインスタンスのメトリックを確認します。 パフォーマンスのボトルネックにより、アクセスの問題が発生する可能性があります。 ECSインスタンスにパフォーマンスのボトルネックがある場合、ECSインスタンスをアップグレードできます。
ヘルスチェックの失敗により、SLBが502エラーを報告
ヘルスチェックに失敗した場合は、「ヘルスチェック例外のトラブルシューティング」をご参照ください。 SLBのヘルスチェック機能が無効になっていて、バックエンドサーバー上のwebサービスがHTTPリクエストを処理できない場合、502エラーが発生します。 たとえば、webサービスは実行されていません。
ヘルスチェックは成功しましたが、webアプリケーションで502エラーが報告されました
502エラーは、SLBがクライアントからのリクエストをバックエンドサーバーに転送できるが、バックエンドサーバー上のwebアプリケーションがリクエストを処理できないことを示しています。 バックエンドサーバー上のwebアプリケーションの構成と実行ステータスを確認する必要があります。 たとえば、webアプリケーションがHTTPリクエストを処理するために使用した時間が、SLBのタイムアウト期間を超えているとします。
レイヤ7 (HTTPまたはHTTPS) リスナーの場合、デフォルトの接続リクエストのタイムアウト時間は60秒です。 バックエンドECSインスタンスがPHPリクエストを処理するのに60秒以上かかる場合、SLBは504ステータスコードを返します。 レイヤ4 (TCPまたはUDP) リスナーの場合、デフォルトの接続要求タイムアウト時間は900秒です。 バックエンドECSインスタンスがPHPリクエストを処理するのに900秒以上かかることはほとんどありません。
webサービスと関連サービスが期待どおりに実行されていることを確認します。 PHPリクエストが適切に処理されているかどうかを確認し、バックエンドサーバーによるPHPリクエストの処理を最適化します。 次の例では、NGINXとPHP-FPMを使用します。
処理されるPHPリクエストの数が上限に達しました。
サーバー上のPHPリクエストの総数が、PHP-FPMのmax_childrenパラメーターで指定された上限に達しました。新しいPHPリクエストがサーバーに到達すると、SLBは502または504のステータスコードを返します。
既存のPHPリクエストと新しいPHPリクエストの両方がタイムリーに処理された場合、エラーは発生しません。
既存のPHPリクエストが低速で処理され、NGINXのfastcgi_read_timeoutの値を超えるまで新しいPHPリクエストが待機状態のままである場合、504ステータスコードが返されます。
既存のPHPリクエストが低速で処理され、NGINXのrequest_terminate_timeoutの値を超えるまで新しいPHPリクエストが待機状態のままである場合、502ステータスコードが返されます。
PHPスクリプトの実行時間が上限を超えた場合、またはPHP-FPMがPHPスクリプトを処理するために使用した時間がNGINXのrequest_terminate_timeoutの値を超えた場合、502エラーが発生し、NGINXログに次のエラーエントリが表示されます。
[error] 1760#0: *251777 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: XXX.XXX.XXX.XXX, server: localhost, request: "GET /timeoutmore.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000"ヘルスチェックは静的ページで実行されます。 ヘルスチェックが成功したが、動的リクエストの処理で例外が発生した場合、エラーが報告されます。 たとえば、PHP-FPMが実行されていないため、動的リクエストを処理できません。
サービスアクセスロジックが無効です。
SLBのレイヤー4リスナーのバックエンドECSインスタンスが、SLBインスタンスのIPアドレスを使用してSLBインスタンスにアクセスしないようにします。 バックエンドECSインスタンスがバックエンドサーバーとして追加されたSLBインスタンスのパブリックIPアドレスを介して独自のポートにアクセスした場合、SLBインスタンスに設定されたスケジューリングポリシーに基づいてリクエストがバックエンドECSインスタンスに送信されます。 これは無限ループにつながり、500または502エラーが発生します。
トラブルシューティングの手順
上記のソリューションを使用しても問題が解決しない場合は、次のトラブルシューティング手順を参照して、問題を特定して解決できます。
すべてのクライアントでアクセスの問題が発生していないか確認します。 そうでない場合は、エラーを報告したクライアントがAlibaba Cloud Securityによってブロックされているかどうかを確認します。 また、SLBのドメイン名またはIPアドレスがISPによってブロックされているかどうかを確認します。
500、502、または504エラーが報告されているページを確認して、エラーがSLB、Anti-DDoS、またはバックエンドECSインスタンスの問題が原因で報告されているかどうかを確認します。
Anti-DDoSの問題: Anti-DDoSが設定されている場合は、レイヤー7転送ルールが適切に設定されていることを確認してください。
SLBの問題:
SLBインスタンスがヘルスチェックに失敗したかどうかを確認します。 その場合は、「ヘルスチェックの失敗」をご参照ください。
問題が持続するかどうかを確認するには、レイヤー7リスナーの代わりにレイヤー4リスナーを使用します。
ECSインスタンスの設定の問題: 5XXステータスコードが断続的に発生した場合、バックエンドECSインスタンスに設定の問題がある可能性があります。 クライアントのhostsファイルで、ドメイン名をバックエンドECSインスタンスのIPアドレスに解決し、バックエンドECSインスタンスに問題があるかどうかを確認します。
エラーがバックエンドECSインスタンスに起因する場合は、バックエンドECSインスタンスのウェブアプリケーションログを確認してください。 webサービスが期待どおりに実行されているかどうか、およびwebアクセスロジックが有効かどうかを確認します。 エラーをトラブルシューティングする前に、ECSインスタンスのウイルス対策ソフトウェアをアンインストールし、インスタンスを再起動します。
バックエンドECSインスタンスのCPU、メモリ、ディスク、または帯域幅にパフォーマンスのボトルネックがあるかどうかを確認します。
ECSインスタンスがLinuxを実行している場合は、バックエンドECSインスタンスのTCPカーネルパラメーターが適切に設定されているかどうかを確認します。
適用範囲
SLB