Cloudflare Tunnelの古いコネクタがVaultwardenの502調査を長引かせた

セルフホストしたVaultwardenで、iOSクライアントから認証エンドポイントへのPOSTが502を返す障害が起きた。コンテナはhealthyで、ホストのCPU・メモリ・ディスクにも余裕がある。こういうとき、アプリケーションを疑い続けるより先に、リクエストがどのコネクタを通ってoriginへ届いたのかを確認した方が早い。

今回確認できたこと

Flight Recorderでは、認証用の /identity/connect/token に対して502が連続していた。そこで、Vaultwardenコンテナのhealth check、ローカルの /alive、Dockerログ、ホストのリソースを順に確認した。

• Vaultwardenコンテナは稼働中で、health checkは正常。
• ローカルのhealth endpointはHTTP 200。
• 502発生時刻に、Vaultwarden側には該当する認証リクエストの記録がなかった。
• ホストにOOM、ディスク逼迫、CPU枯渇、カーネルエラーは見当たらなかった。

この組み合わせは、「Vaultwardenが502を返した」というより、Cloudflareから選ばれたTunnelコネクタ経由のリクエストが、Vaultwardenまで到達していない可能性を示す。コンテナのhealthyは、外部経路全体のhealthyを意味しない。

古いホストのTunnelが残っていた

構成を棚卸しすると、移行前のRaspberry Pi側にも同じTunnelへ接続する cloudflared が残っていた。新ホスト側のTunnelは稼働しており、HA接続も確立していたが、旧ホスト側のサービスもenabledのまま動いていた。

同じTunnelに複数のコネクタを接続すること自体は、冗長化のための正しい構成になり得る。今回の問題は「複数だから必ず悪い」ということではなく、移行前ホストのコネクタが、どのingress設定とoriginを使い、現在も意図した状態なのかを確認しないまま残っていた点にある。

旧ホスト側のサービスを、移行後の正しい実行場所であることを確認したうえで停止・無効化した。

sudo systemctl disable --now cloudflared.service

systemctl is-active cloudflared.service   # inactive
systemctl is-enabled cloudflared.service  # disabled

停止後のエンドツーエンド確認

サービスを止めた後、単にコンテナの状態を見るだけではなく、外部ホスト名から複数の経路を確認した。

curl -i https://example.com/alive
curl -i https://example.com/api/config
curl -i -X POST https://example.com/identity/connect/token \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  --data 'grant_type=password&client_id=web&username=invalid@example.invalid&password=invalid'

結果は、health endpointと設定endpointが200、偽の認証情報に対する認証endpointが400だった。認証情報が正しいという意味ではないが、少なくともリクエストがCloudflare Tunnelを通ってVaultwardenの認証処理まで届く状態になったことは確認できる。資格情報を実際に送信する必要がない点も重要だ。

原因を断定しない

旧コネクタを停止した直後に外部経路は正常化したため、古いTunnelレプリカが原因だった可能性は高い。ただし、調査中に新ホスト側の cloudflared もユーザーが実施したパッケージ更新によって再起動され、バージョンが更新されていた。二つの事象が近接して起きたため、「旧コネクタの停止だけが復旧原因だった」とまでは証明できない。

障害対応では、復旧したことと、原因を証明したことを分けて記録する方がよい。今回確実に言えるのは、旧ホスト側のTunnelを停止・無効化し、新ホスト側だけを稼働させた後、外部経路が200/400という期待される応答になったことまでである。

移行時に残したくないチェック項目

• Tunnelのコネクタが、旧ホスト・新ホストの両方でenabledになっていないか。
• 各コネクタのingress設定が同じoriginを指しているか。
• originのhealth checkと、外部ホスト名からのhealth checkを分けて実行する。
• アプリケーションログにリクエストがない場合は、Tunnel・ロードバランシング・経路を優先して調べる。
• 復旧後も、停止した旧サービスの自動起動が無効になっていることを確認する。

「コンテナはhealthyなのに外から502」という現象は、アプリケーションの故障とは限らない。複数ホストをまたぐ移行では、動いているプロセスの数を減らすことが、修理より先に必要になる場合がある。