01
最初に分からなかったこと
Nextcloudを自宅サーバーで動かしたとき、ブラウザからアプリへ通信が届くまでの経路が分かりませんでした。Nginx、DNS、ルーター、ポートという言葉を別々に覚えても、どこで何が起きているのかを説明できなかったためです。
このノートでは、Nginxを『外から届いたリクエストを受け取り、正しいサービスへ案内する入口』として捉えます。設定を丸ごとコピーするのではなく、通信が進む順序から理解します。
02
Webサーバーとリバースプロキシ
Webサーバーとして使う場合、Nginx自身がHTMLや画像などの静的ファイルを返します。一方、リバースプロキシとして使う場合は、受け取った通信をNextcloudなど別のアプリへ転送し、その返答を利用者へ返します。
複数のアプリが一台のサーバー内にあるときも、利用者はNginxという一つの入口へアクセスできます。Nginxはホスト名やパスを見て、どのアプリへ渡すか判断します。
- ↳静的ファイルを直接返す
- ↳アプリサーバーへ通信を転送する
- ↳HTTPSの終端を一か所へまとめる
- ↳アクセス記録を入口で確認する
03
通信を順番に追う
接続できないときは、すべての設定を同時に変えず、名前解決、到達経路、Nginx、アプリの順で確認します。宅内からだけ接続できるのか、Tailscale経由なら届くのかも切り分け材料になります。
- ↳ドメイン名が意図したIPへ変換されるか
- ↳利用端末からサーバーの対象ポートへ届くか
- ↳Nginxのアクセスログに要求が残るか
- ↳Nginxから転送先アプリへ接続できるか
- ↳アプリが期待するHostやHTTPS情報を受け取れているか
04
最小構成を読む
次は考え方を確認するための例です。実際に公開するときはHTTPS、認証、アクセス制御を加え、環境に合う値へ置き換えます。
EXAMPLEserver {
listen 80;
server_name cloud.example.com;
location / {
proxy_pass http://192.168.1.20:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}- ↳server_name: どの名前で届いた通信を扱うか
- ↳location: どのパスを対象にするか
- ↳proxy_pass: 実際のアプリが待っている場所
- ↳proxy_set_header: 元の通信情報をアプリへ伝える
05
うまくいかないときの確認
設定を変更したら、構文確認をしてから再読み込みします。エラー画面だけを見るのではなく、Nginxと転送先アプリの両方のログを同じ時刻で追うと原因を見つけやすくなります。
- ↳設定ファイルの構文エラー
- ↳転送先のIP・ポート間違い
- ↳ファイアウォールでの遮断
- ↳HostヘッダーやHTTPS判定の不一致
- ↳アップロード容量・タイムアウトの不足