【情報求む】現代のWEBで 502 Bad Gateway が利用者側で起きることは考えられるか
最近 502 Bad Gateway が発生する事案に遭遇した。そこで争点となったのは利用者側で起きたかどうかである。理論上は利用者側でも起きうると思われるが、浅学にして現実的な原因の構成に至らなかったため、読者の知恵をお借りしたい。
背景: チケットサイトでの購入
最近あった 502 Bad Gateway が利用者側で起きたかどうかが争点になる事案について説明する。
事案の発生
筆者は某社 (特定できてもみなさまの心に留めてください) のチケット販売サービスを利用しようとした。いざチケットを購入しようとして購入ボタンを押したところ、購入完了画面の代わりに 502 Bad Gateway が表示された。不覚にもスクリーンショットなどを取り忘れたのでChromeの閲覧履歴しかないが、図1がその様子である。
この購入完了画面が表示されないというのは、法的に購入が完了したと見なされないことがあるため、実は重大な話である。サポートにも確認したが、このサービスでも利用規約で購入完了画面の表示をもって契約完了となる旨を定めている。そのため、購入完了画面が表示されていなければ、購入が成立していないのに課金しているとても困った状態ということになる。返金や不整合の修正などが必要になってきてしまう。
6/6 追記: つまり、電子消費者契約法に定める、事業者の承諾の意思表示が届かなかった状態ということである。
もちろん、通信環境の不具合等サービス側の問題でない部分で表示できないこともあり、その場合の免責も定めている。一方、サービス側の問題があればそれは依然として責任を免れるものではない。つまり、購入完了画面を表示できなかったという事象だけでなく、原因がサービス側にあったか利用者側にあったかが大きな争点になる。
サポート問い合わせ
この事案に関連して詳細は省くが筆者に少額の損害が発生したのでサポート問い合わせを行った。
最初の回答は聞き方が悪かったようで以下のように要領を得ないものであった。
当サービスはインターネット通信を行っている以上、 通信環境の不具合等、ご使用機器の利用環境に関する事情等により本サービスが 正しく作動しない場合がありえることを十分理解、認識したうえで 当サービスをご利用していただきますようお願い申し上げます。 また、それらによってお客様が受けた影響や損害等に関して、 当社は一切責任を負いませんことをご理解賜りますようお願い申し上げます。
なお、当システムには異常は発生しておりません。
電波状況やアクセス集中等、さまざまな要因が考えられますが これは当システムに限って起こる現象ではなく、 インターネット通信上、起こりうる症状でありますことを ご理解賜りますようお願い申し上げます。
[5/31追記] 502 Bad Gateway は確かにネットワーク通信に起因して起きるが、現代のWEBにおいてネットワーク通信はサービス内部でも行われるのが一般的である。後述するようにこのサービスにおいてもサービス内部の通信があると推定される。そのため、「インターネット通信」の問題である、つまりあたかもサービス側に属さない、利用者側に限った問題であるかのような説明をするのは適切とはいい難い。
その後色々確認した結果、某社の主張をまとめると以下のようであった。
- 502 Bad Gateway の多くは利用者側で起きる
- 念の為サービス側でないかシステム部門で確認したが購入完了画面を送信したログがあった
- よって、今回の 502 Bad Gateway は利用者側で起きたものである
筆者としては1も2も腑に落ちないところがあったが、理論上は利用者側で起きる可能性が0ではないと思い、損害が少額かつ証拠も不十分ということで、それ以上追求しないことにした。
本題: 実際どういうメカニズムで起きうるのか
以上で金の問題はとりあえず解決したことにしたものの、技術的な話は残っており、これを解決する必要がある。自社サービスでも同様の問題が起きる可能性もあるし、何より筆者は博士中退の研究者の無精卵の成れの果てなので、事実を明らかにすること自体にも興味がある。
502 Bad Gateway
まずそもそも 502 Bad Gateway とは何であったか。これはWebサービスと利用者の間でデータをやり取りするプロトコルHTTPで使われるエラーコードである。Webサーバ自体よりは、通信経路上のHTTPを喋る各種装置がそこより先の通信がうまく行っていないことを示すために使われることが多い。
このようなHTTPを喋る装置としては以下のようなものが考えられる。サービス側に属するものとしては、
- LB (ロードバランサー)
- リバースプロキシー
などがあり、利用者側に属するものとしては、
- 各種プロキシー
- 利用者のPCにインストールされているネットワークツール
などである。
なお、言うまでもなく、電波状況や通信環境の不具合等による通信エラー単体では 502 Bad Gateway は発生しない。あくまでそこより利用者側にHTTPを喋る装置が存在するときのみ 502 Bad Gateway に変換される可能性が0でなくなる。
接続の状況
では、今回の事案における接続の状況を整理しておく。今回のサービス側の構成は、特徴的なURLと、レスポンスヘッダと、使用しているIP帯から、AWS上に構築されたサービスであり
- Struts2で開発されたWebサーバ
- 前段にあるApache
- AWS ALB
からなると推定される。これはあくまで筆者の推定にすぎない点には留意していただきたい。特にAWSならALBが入っているはずだというのは筆者の偏見による。
また利用者側は、旅行先のホテルのFree Wi-Fiを利用してMacから接続していた。このFree Wi-FiはCaptive Portalとかはなく、単純にSSIDとキーが渡されるだけの雑なタイプである。また、Macにはセキュリティソフト(ESET)がインストールされていて動作中であった。接続にVPNは使用していなかった。
まとめると以下の図2のようになる。
サービス側が原因の場合
まず、サービス側が原因の場合はわかりやすい。Webサーバの前段にApacheとALBがあるので、これらが 502 Bad Gateway を返してしまっていることが考えられる。調べてみるとテクニカルサポートが 「ALB 502 エラーの原因切り分け Yes/No 診断」を作ってみた 記事を出しているくらいなので、世間的にもよくあることなのだろう。
それ以外にもWebサーバ自体が 502 Bad Gateway を返したということも考えられるが、記事の前提がひっくり返るので置いておくことにする。
ちなみに、購入完了画面を送信したログがあった、という説明が、Webサーバ、Apache、ALB、いずれのログを指しているのかは問い合わせていないので不明である。
利用者側が原因の場合
今度は利用者側が原因の場合を考えてみる。以下の3つのパターンがあると思われる。
- インターネット(通信事業者)
- ホテルWi-Fi
- セキュリティソフトやVPNなど端末内にインストールされているソフトウェア
ただ現代においては 1, 2 のパターンはかなり無理があると思っている。過去にはCaptive Portalであったり、データキャッシュしてくれるhttp proxyであったり、通信の最適化であったり、httpレスポンスを勝手に差し替えるようなシステムが挟まっていることは多かった。しかし、httpsがデフォルトになった今は改竄が検知されるのでほぼ絶滅したという認識である。万が一存在しても 502 Bad Gateway よりも優先されてブラウザ上に警告が出るので、今回の事案でも即座に気づいたはずである。今回の場合、ホテルには1泊2日と3泊4日の2回利用したが、その間同様の 502 Bad Gateway 画面が表示されたのはこれ1回で、改竄警告は当然1回もなかった。
また3のパターンもオレオレ証明書のインストールなど細工が可能になるので理論上可能だが、少し考えにくいように思う。なぜなら、タイムアウトなどがあれば普通に接続を切ってしまえばいいので、わざわざ 502 Bad Gateway を出す必然性がなさそうだからである。一方、実際 502 Bad Gateway とかを返すフィルタリングソフトとかがあるらしいという噂も聞くのでもしかしたらそういうこともあるのかもしれない。ちなみにESETがどちらに該当するソフトウェアなのかは把握できていない。
以上をまとめると、筆者は、初手で利用者側の責任を疑うのはかなり無理筋だと考えている。これを読んでいる読者はどう思うだろうか?
ご意見求む。
余談: 502 Bad Gateway が発生したと利用者から問い合わせを受けたらどう回答すべきか
自サービスで実際に問い合わせを受けた場合サポートにはどう回答してもらうのがいいだろうか?たとえば利用者側の問題一点張りにするのは、サービス側でも起きうる問題である以上それは悪手であるように思う。サービス側の問題で不便をかけたことを謝りつつ、調査する、ただし利用者側の問題という結論になる場合もある、という旨を伝えるのが良いのではないだろうか。
ご不便をおかけして申し訳ありません。
502 Bad Gatewayとなった原因を調査の上、必要な対応をさせていただきます。
なお、502 Bad Gateway は、サービス側だけでなく利用者側の環境が原因でも起きうるため、調査結果によっては当社が責任を負うことができかねる場合があることを、あらかじめご了承ください。
こんな感じだろうか?