HTTPS / リバースプロキシ チェック

HTTPS チェックの仕組み

チェックは 17NAS のサーバーから実行され、流れは「DNS 名前解決 → TCP 接続の確立（443）→ TLS ハンドシェイク → 証明書チェーンとドメインの検証 → HTTP リクエストを送ってステータスコードを読み取る」です。証明書検証はシステムの信頼ストアを使用し、期限切れ・ドメイン不一致・自己署名などを区別して報告します。チェック全体で読み取るのはステータスコードとレスポンスヘッダーのみで、ページ本文はダウンロードしません。

よくある HTTPS の問題

• 証明書の期限切れ：Let's Encrypt の証明書は 90 日間有効で、自動更新に失敗するとブラウザは接続を拒否します。
• ドメイン不一致：証明書がアクセス先のサブドメインをカバーしていません（例：証明書は example.com のみをカバーしているのに nas.example.com にアクセスしている）。
• 接続が拒否された、またはタイムアウトしました：ポート 443 が開放されていない、リバースプロキシが待ち受けていない、またはファイアウォールが inbound 接続を遮断しています。
• 502 / 504：入口は正常ですがバックエンドに問題があります。リバースプロキシ設定後にアプリコンテナが起動していない場合によく見られます。

リバースプロキシが 502 / 504 を返す理由

リバースプロキシはリクエストをバックエンドのアプリに転送します。502 は、プロキシがバックエンドのアドレスを見つけたが接続に失敗した、または無効な応答を受け取ったことを意味します。よくある原因は、アプリが起動していない、upstream のホストやポートの指定ミス、コンテナネットワークの不通です。504 は、プロキシがバックエンドに接続したが応答待ちでタイムアウトしたことを意味します。よくある原因は、アプリのフリーズ、過負荷、バックエンド側ファイアウォールによる接続破棄です。どちらのステータスもプロキシ層は動作しており、問題はプロキシとバックエンドの間にあることを示します。

次に確認すること

名前解決が正しくなければ DNS / DDNS チェックで向き先を確認、接続に失敗したら開放ポートチェックで 443 が到達可能か確認、通信事業者 NAT の内側にいる場合は CGNAT チェックでグローバル IP の有無を確認、インターネットからの inbound が必要ならポート転送ジェネレーターで転送設定を確認、IPv6 のみの環境なら IPv6 テストでデュアルスタック状態を確認してください。