DNS からアプリまでの1つのリクエストを追跡してください。

期待するルートを書き留めてください

このウォークスルーは、あなたが管理する Linux VPS、動作する SSH セッション、無害な /healthz エンドポイントを持つアプリケーション、および管理下のドメインの権威 DNS 設定へのアクセスを前提としています。例のアプリは次でリッスンします: 127.0.0.1:3000。Caddy が公開リバースプロキシです。アプリが別のスーパーバイザーやプロキシを使用する場合は、診断順序を維持し、そのドキュメントを使用してください。

api.example.com と 203.0.113.10 はドキュメントのプレースホルダーであり、稼働中のサービスではありません。自分のシステムに対してチェックを実行する前に、両方を置き換えてください。実際のホスト名、意図した IP アドレス、アプリのポート、サービス名を1か所に記録してください。コンフィギュレーターで VPS ホスト名を設定しても、公開 DNS レコードは作成されません。

DNS は意図したアドレスを返します。
接続は意図したサーバーとポートに到達します。
TLS はリクエストされたホスト名を認証します。
プロキシはリクエストを正しいアップストリームに転送します。
アプリケーションは期待される応答を返します。

両方のアドレスファミリーを確認してください

VPS の外部のマシンから、公開する予定のレコードをクエリしてください。 dig は BIND の DNS ツールに属します。パッケージ名は異なります。これらのコマンドは answer セクションを要求し、レコードタイプ、アドレス、残りのキャッシュ寿命を確認できます。参照: BIND dig リファレンス.

dig api.example.com A +noall +answer
dig api.example.com AAAA +noall +answer

返されたすべてのアドレスを意図した宛先と比較してください。AAAA レコードは、IPv6 ルーティング、リスニング、フィルタリングがそのアドレスで機能する場合にのみ公開してください。古い AAAA レコードは、一部のクライアントを A レコードとは異なる場所へ送る可能性があります。CDN や DNS プロキシを意図的に使用している場合、そのアドレスは正しい可能性があります。VPS が必ず現れなければならないと仮定せず、その追加ホップを記録してください。

空白の回答は、完全な dig 応答を詳しく調べる必要があります。それは、そのタイプのレコードがない、名前が存在しない、または解決の問題を意味する可能性があります。編集する前に、どの DNS サービスが権威であるかを確認してください。古い値と TTL を記録し、そこで意図した変更を行い、既存のキャッシュが期限切れになった後に新しい結果を比較してください。無関係な編集を繰り返すと、タイムラインが理解しにくくなります。

接続失敗と証明書失敗を区別してください

サーバー外部から小さなエンドポイントをリクエストしてください。アプリケーションが HEAD を実装していると仮定せず、GET を使用してください。Curl のタイムアウトオプションはチェックを制限します。その詳細出力は接続と TLS の進行状況を示します。 Curl はこれらのオプションと証明書検証を文書化しています.

curl --verbose --connect-timeout 5 --max-time 10 https://api.example.com/healthz

解決エラーは DNS に戻ります。接続拒否は接続が能動的に拒否されたことを意味します。タイムアウトはルーティングやフィルタリングに関係する可能性があり、どのファイアウォールが原因かを特定しません。証明書エラーは、期待される安全な接続が確立されなかったことを意味します。証明書チェックの無効化を恒久的な修正にしないでください。

ホスト名を TLS リクエストに保持しつつ特定のオリジンを比較するには、curl のアドレスオーバーライドを使用します:

curl --verbose --connect-timeout 5 --max-time 10 --resolve api.example.com:443:203.0.113.10 https://api.example.com/healthz

これが成功し、通常のリクエストが失敗する場合は、DNSと中間にあるものを比較してください。この上書きはDNSを編集しません。AレコードとAAAAレコードの両方が存在する場合は、通常のリクエストを次のクライアントから繰り返してください: --ipv4 と --ipv6 対応するネットワークを実際にサポートするクライアントから。

接続のサーバー側を調査してください

VPS上で、リッスンしているTCPソケットを確認し、アプリに直接クエリを送信します:

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

ss はリスナーと、十分な権限があればそのプロセスを表示します。ループバックリスナーはローカルで到達可能ですが、その存在だけでは外部アクセスについて何もわかりません。アップストリームのssマニュアルを参照してください。アプリへの直接リクエストが失敗する場合は、DNSを変更する前にプロセス診断ガイドへ進んでください。

この単一アプリ構成では、関連するCaddyfileブロックは次のとおりです:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

ホスト名とアップストリームはあなたのアプリケーションに一致する必要があります。Caddyのリバースプロキシディレクティブはリクエストを設定されたアップストリームへ転送します。ここに任意のドメインを置いても、そのドメインを制御できるわけではありません。編集前に既存の設定を保存してください。パッケージ化されたサービスとこのファイルパスでは、まず検証し、検証が成功した後にのみリロードしてください:

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy

コマンドの目的は異なります。検証は設定の読み込みをチェックし、リロードは変更を適用します。インストールされたサービスの実際のファイルパスと権限を確認してください。 Caddyのコマンドリファレンスで検証とリロードの動作を説明しています。

完全なパスを検証し、証拠を保持してください

通常の公開証明書自動化には、Caddyは正しいDNS、外部から到達可能なチャレンジポート、リスナーをバインドする権限、永続的で書き込み可能な証明書ストレージを必要とします。HTTPチャレンジとTLS-ALPNチャレンジはそれぞれポート80と443を使用します。DNSチャレンジは別のセットアップです。 CaddyのHTTPS前提条件を参照してください。ファイアウォールルールを確認する際は、管理アクセスを維持してください。

参考結果: ローカルエンドポイントは {"status":"ok"}を返し、外部HTTPSリクエストは同じ小さなボディを返し、curlは証明書検証の成功を報告します。これらはこの例で期待される観察結果であり、OffVPSサーバーから記録された結果ではありません。また、通常のアプリケーションアクションを1つ実行してください。浅いヘルスエンドポイントは通過しても、データベース依存のルートは失敗する場合があります。

リクエスト時刻、ホスト名、アドレスファミリ、最初に失敗したレイヤーを記録してください。その報告は「ドメインが壊れている」よりも役立ちます。パスが機能したら、再現可能なリリースガイドを使用して、同じチェックをすべてのデプロイに組み込んでください。

使用したドキュメント

このページの主な参照資料。ご自身の環境にインストールされているバージョンのドキュメントを確認してください。