同一のサーバー（グローバルIP）上で、複数のサブドメイン（例: www.ice-military.com や tech.ice-military.com）をそれぞれ独立した個別 .conf と固有のSSL証明書で運用している環境において、サーバーのIPアドレスを直接ブラウザなどで叩いた際に起きる挙動と、そのセキュリティ的な意味についてまとめました。
1. 現状の構成と正しい住み分け
- 個別証明書・マルチドメイン運用
ワイルドカード証明書を使わず、各サブドメイン（wwwやtech）ごとに専用の.confファイルと専用のLet’s Encrypt証明書を割り当てています。 - 正常時のルーティング
正当なドメイン名（SNI）でアクセスされた通信は、それぞれの設定ファイルが完璧に受け持ち、お互いに干渉することなく安全かつスムーズに動作しています。
2. IP直打ちや未知のホスト名でアクセスしたときの挙動
ドメイン名を介さず、サーバーのIPアドレスを直接叩いた場合：
- Nginxの迷子状態：
server_nameによる振り分け（SNI判定）ができないため、Nginxがどちらの.confに流していいか迷子になる。 ERR_CONNECTION_TIMEOUTの発生：
結果として、パケットが宙に浮いたまま処理されず、ERR_CONNECTION_TIMEOUT（タイムアウト）として沈黙する。
3. なぜ「何もしない（そのままで放置）」が正解なのか？
下手に汎用のキャッチオール（server_name _ ;）や複雑なリダイレクト、証明書のバッティングを誘発する設定をねじ込もうとすると、正常に稼働している個別のSSL環境を壊してしまうリスクがあります。
同一IP上で複数の .conf がそれぞれの server_name（SNI）でのみルーティングを行っている環境では、IP直撃や未知のホスト名によるアクセスは宛先の判断がつかず、Nginxが迷子になります。結果としてサーバーが応答を返さず、ブラウザ側は ERR_CONNECTION_TIMEOUT（タイムアウト）となります。
あえて応答を返さずに沈黙させるこの状態は、セキュリティや運用面において非常に優れたメリットを持っています：
- 存在の秘匿：スキャナーやボットに対して余計なエラーページや固有の証明書情報を一切与えず、「このIPには応答するWebサーバーが存在しない（あるいは完全に沈黙している）」ように見せかけられます。
- リソースの保護：無駄なTLSハンドシェイクやエラーレスポンスの処理を行わないため、サーバーの無駄なリソース消費を防ぎます。
💡まとめ
個別証明書と個別の .conf で複数のサブドメインを堅実に守っている環境において、IP直撃に対するタイムアウトは偶然の不具合ではなく、「不審なアクセスを無言でドブに捨てる、最も安全で理想的な防衛状態」です。
もしこれがワイルドカード証明書と1枚の .conf 構成であれば、Nginxは迷子にならず、どんな適当なアクセスやスキャナーに対してもTLSの握手を成立させて何かしらのページを返してしまいます。つまり、「あえて設定や証明書をバラバラにして迷子（タイムアウト）を生み出すこと」自体が、ボットからの防御や存在の秘匿として強力に機能していたというわけです。
無理に汎用キャッチオールを設定して事故を起こすリスクを冒すより、今の「正当なアクセスだけを綺麗に通し、怪しい直撃や未知のアクセスはタイムアウトで沈黙させる」という状態をそのままキープするのが、マルチドメイン環境における大正解です！
実を言うと、こっちの別館を立ち上げた時に.confファイルを別けた理由が「1つのファイルがごちゃごちゃしてメンテナンスしづらくなるのを避けたかった」「設定を綺麗に分割したかった」っていうただの保守性のための分割（整理整頓）だったんですけど、結果的にセキュリティ上の強力な「サイレント防衛網」として機能していたなんて思いもよらなかったです(ﾉ∀`)
コメント