こんにちは、Twilioマーケティング部チーフの高橋です。
普段からさまざまなウェブサイトに訪問していると、まれに「502 Bad Gateway」というエラーメッセージが表示されることがあります。いきなり「502 Bad Gateway」と表示され、何が発生したのかわからずに焦ってしまった……という方も多いのではないでしょうか?
さらに弊社が提供しているコミュニケーションAPIサービス"Twilio"を利用されている最中に通話断が発生したり、一部の処理が正常に実行されなかったりした際、502エラーが発生していたというケースを過去に経験された方々も少なくないと思います。
そこで本記事では「502エラーって何?」「502エラーが表示されたけどどうすればいいの?」とお困りの方向けに、エラーの原因と対策方法を解説します。またTwilioをすでにご利用いただいている方にも、お役立ていただける問題の切り分け方法をご紹介します。
目次
502 Bad Gatewayエラーとは

502 Bad Gatewayエラーは、サーバー間で通信の不具合などが発生し、通信状態に何かしらの問題がある時に表示されるエラーコードです。発生する原因が1つだけではないため、サービス提供側はさまざまなポイントを見ながら原因を特定し、解決方法を試すということが必要になります。
ちなみにサービス利用者の方で502エラーが発生した場合は、サービス提供側の対応を待つのみとなります。500番台のエラーはサーバー側の問題となるため、502エラーに関しても、サービス利用者側では一旦静観するしかありません。
502 Bad Gatewayエラーの対処方法
ここではサービス提供側がおこなえる502エラーの対処方法について、一般的なものを4つご紹介します。ちなみにTwilioをご利用いただいている方の場合はこちらまでスキップしていただいても構いません。
対処方法①:ログを調べて、変更点やステータスを確認
502エラーの発生原因はいくつか考えられますが、何かしらの作業による設定ミスによってエラーが発生している可能性があります。
サーバーのログにはサーバーが正常に稼働しているかどうかがわかるステータスがあるため、まずはそちらを確認してみましょう。もしくは直近で作業した記憶があればそれが原因である可能性もあるため、設定ミスがないかを確認してください。
もし「作業をいつおこなったか見当がつかない」という方は、502エラーが発生した日付を特定するため、Google Analyticsのようなアクセス解析ツールでアクセスが減少し始めた日付を探るという方法もあります。これによって見るべきログを絞り込めます。
その上で502エラーが発生していそうな設定ミスが発見できた場合は、設定を修正するか変更前の状態に戻して、502エラーが解消されるかを検証しましょう。
対処方法②:サーバー側の問題かを確認
直近で何も作業をおこなっていない場合は、単純にサーバー側のメンテナンスなどによってサーバーが停止している可能性が考えられます。
外部サービスのサーバーを利用している方は、サーバー会社のメンテナンス情報を確認して、問い合わせてみることもおすすめします。
サーバー会社の問題が修正されれば、自然と502エラーも解除されることでしょう。
対処方法③:DNSの変更や反映を確認
DNSサーバーの設定が原因で502エラーが発生している場合があります。
DNSサーバーとは、ネームサーバーとも呼ばれていますが、ドメイン名とIPアドレスを変換する処理をおこなっているサーバーです。
直近でIPアドレスやドメインを変更をおこなった場合は、DNSサーバーへの反映が完了していない可能性があります。変更の反映には時間がかかる場合もあるため、反映が完了するまで待つしかありません。
対処方法④:コードの記述ミスを修正
WordPressをはじめとしたCMSにはプラグインが存在していますが、このプラグインのアップデートが原因で502エラーが発生している可能性もあります。プラグインを無効化した上でエラーが解消されるか確認してみてください。
それでも解消されない場合は、プラグインが原因ではないため、直近で記述したコードがあるかを確認して修正しましょう。原因が特定できない場合は、バックアップを日頃から取っておくことで、502エラーが発生した日までロールバックするという対処方法もあります。
これまでは一般的な502エラーの改善方法4つをご紹介しました。続いて、弊社が提供しているTwilioの502エラーにおける改善方法をご紹介します。
Twilioの502エラー発生時の問題切り分け方法

Twilioのようにクラウド環境のサービスを利用されている場合、パブリックインターネットや利用されているネットワーク環境、およびTwilioネットワーク環境など複数の通信要因が加わるため、502エラーの発生箇所を特定するのは非常に困難です。
Twilioのシステムが502エラーを返していることから、このエラーがTwilioによる不具合や問題で発生したと思われるお客様も多いかと思います。しかしこの502エラーは「お客様のWebサーバー(TwilioがアクションURLを送る宛先)と通信できなかった」ものすべてが含まれるため、必ずしもTwilioに原因があるとは断定できません。
しかし発生した可能性がある箇所を切り分けて検証していくことで、発生原因をある程度特定し、次に対処すべき手段を検討できます。
手順①:利用環境を確認
502エラーが発生した場合は、まずTwilioの管理画面にログインして、502エラーが発生したコールやSMSのログ詳細を確認していきましょう。
このときに叩かれたURLのWebサーバー環境で、エラーが起きた時間帯にWebサーバー負荷やネットワーク障害などの問題が発生していないかを確認します。
もしこちらで問題を確認できなかった場合は、Webサーバー側のアクセスログとアプリケーションログを確認し、Twilioからアクセスが来ている場合は実行されたアプリケーションの処理が正常に終了したかを確認します。
処理が正常に実行されなかった場合、Twilioはこの応答を得られなかったために502エラーを出したという結論になります。そもそもアクセスが来ていなかった場合は、Twilioからお客様のWebサーバーまで通信が届いたのかを調べる必要があります。
手順②:URL間違えやWebサーバー側のネットワーク問題かの切り分け
別の手法(ブラウザやwgetコマンド等) を使って先ほどと同じURLへアクセスを試してください。もしここでエラーになったり、接続できなかったりした場合には、指定しているURLが間違っていると考えられます。
該当のURLにアクセスできる場合は、時間帯を変えて複数回リクエストを送信してみましょう。この際に「何回かに1度の割合で失敗する」または「特定の時間で失敗する頻度が上がる」等の特徴が見られた場合、お客様のWebサーバーの負荷またはネットワーク側の問題であると考えられます。
お客様のWebサーバーまたはネットワーク側の問題ではないと判断した場合は、次の手順へ進んでください。
手順③:Webサーバー周辺の原因かの切りわけ
ロードバランサーをご利用の方や、ダイナミックDNSをご利用の方は、それぞれこれらを抜きでアクセスできる手法で前述の問題を切り分けていきます。
Webサーバーとネットワークに原因がなかった場合でも、ロードバランサーやダイナミックDNSが通信を阻害する要因を持っていることがあります。ファイヤーウォールを設置している場合も、可能性の有無を切り分けてみましょう。
これらのコンポーネントが多段構成になっている場合、それぞれのコンポーネントのアクセスログを確認しながら、どこまで通信が通っているのかを検証します。

例えば、「ユーザー → インターネット → ファイヤーウォール → ロードバランサー → ウェブサーバー」のような構成の場合でご説明します。
ファイヤーウォールへは当該URLのアクセスログがあるにも関わらず、ロードバランサーにはない場合、ファイヤーウォールが原因と特定できます。
ロードバランサーにアクセスログがあるが、Webサーバーにはない場合、ロードバランサーが原因と特定できます。
さらにファイヤーウォールにもアクセスログが来ていない場合、Twilioとお客様のネットワーク間で問題が発生していることになります。
手順④:Twilioとお客様のネットワーク間で問題が発生している場合
手順通りに検証した結果、Twilioとお客様のネットワーク間で問題が発生していると特定できた場合は、Twilioのネットワーク環境ではないため、調査できる範囲が限られてきます。
少しでもお役に立てるよう、弊社でも可能な範囲で追跡調査をおこなわせていただきます。以下の情報をお書き添えの上、お問い合わせください。
- Accound SID(ACから始まる32桁の番号)
- 502エラーが発生したコールやSMSの CallSID/MessageSID (管理画面からログをCSVでエクスポートしていただいても大丈夫です)
- 発生頻度や発生傾向や特徴など
- このコールやSMSを利用している簡単なフローのご説明
- 上記で切り分けをおこなっていただいた際の結果、デバッグログ等、お出しいただける情報や記録があれば併せて添付してください。些細なものでも結構です、手がかりになることがあります。
502エラーの多くはTwilioが管理できない外側のネットワークで発生するため、再現性がない事例が多いです。また一過性のものである場合、原因の特定が困難であるということも少なくありません。
問題の軽減措置にはなりますが、 fallbackURLをTwimlbin、または現在メインでご利用中のWebサーバーのネットワークとは別のネットワークにあるサブWebサーバー等で設定することを推奨します。
fallbackURL は、メインで指定しているURLへのアクセスが失敗した際に叩かれるURLです。こちらをご利用いただくことで、そもそもTwilioがURLを発行したのかどうかの切り分けが可能となります。また中間のネットワークが原因だった場合、fallbackURL側へのアクセスにより処理を再度実行できるため、サービス断を防ぐことができます。