「nginx -t」が成功したからといって、サイトが実際に開けるとは限りません。 当サイト全体が利用不能になった事例がありました：構文チェックはすべて合格でしたが、正確なlocationディレクティブにおける301リダイレクトとtry_filesが相互にリダイレクトし、ブラウザが「リダイレクト回数が多すぎます」と直接エラーを表示しました。このツールは2つのものを提供します：nginx設定の骨格（すべての落とし穴がコメントに記載されています）と、実際のHTTP自己診断スクリプト（構文チェックだけでなく、ステータスコードおよびリダイレクト回数も確認します）。
1行に1つ記述します。ホームページは必須であり、サブページは最低限それぞれ1つずつ必要です。
—
—
1・正確な location + 301 により無限ループが発生します。1つ記述する location = /path { return 301 …; }、そして try_files また、リクエストを内部で同じ location へ再びリダイレクトすると、ブラウザが「リダイレクト回数が多すぎます」と報告し、サイト全体が開けなくなります。nginx -t 完全に検出できません。
2 · 長期間キャッシュ + バージョン番号なし = 変更が「反映されていないように見える」。同じミスを私たちは3回繰り返しました（CSS で2回、JS で1回）。ルールは単純です：expires を設定した場合、CSS/JS にも同様に設定する必要があります。 ?v=；1回変更 → 1回バージョンアップ。
3・<base href> はすべての相対リソースより前に記述する必要があります。に記述する <link> その後、サブページが CSS を誤ったディレクトリで解析し、スタイルがサイレントに無効化されます——親ページでは一切検知できません。
4・バックエンドデータを basic auth の後ろに配置して fetch で使用しないでください。ブラウザによるサブリクエストの資格情報キャッシュは制御不能であり、ページは「読み込み中」のまま永遠に固まる。これを「ページログイン＋データに暗号化キー付きパラメータ付与」方式に変更。
5 · ローカルプロキシによる誤検知。サイトの稼働状態を判定する際は、必ずこれを追加します。 --noproxy '*'；我々は、プロキシが返した 410 を「サイトがダウンした」と誤判定したことがありますが、実際には 200 でした。