ドキュメントルートと設定ファイル
Webサーバが公開するファイルを置く場所を「ドキュメントルート」と呼びます。nginx の既定は /usr/share/nginx/html、Apache httpd は /var/www/html です。ここに index.html を置けばトップページとして表示されます。設定ファイルは nginx が /etc/nginx/nginx.conf、httpd が /etc/httpd/conf/httpd.conf にあり、編集後は構文チェックをしてからサービスを再読み込みします。
Webサーバを起動するとテストページが表示される。だが、見せたいのはそんな初期画面ではなく、自分のコンテンツのはずだ。自分のHTMLはどこに置けばブラウザに届くのか。
そこで知っておくべきなのが、Webサーバが公開するファイルを置く起点となるディレクトリ、ドキュメントルートだ。
ブラウザが http://サーバ名/ にアクセスしてきたとき、Webサーバはこのドキュメントルートの中からファイルを探して返す。とくにファイル名を指定せずディレクトリだけにアクセスされた場合は、既定で index.html を探して表示する。
つまり、ドキュメントルートに index.html を置けば、それがそのサイトのトップページ（ホームページ）になる。HTMLファイルや画像など、サイトの表示に必要なデータは、すべてこのディレクトリ以下に配置していく。
🗂 その置き場所は、どこで決まっているのか
ドキュメントルートの既定の場所はWebサーバごとに決まっている。nginx は /usr/share/nginx/html、Apache httpd は /var/www/html だ。
たとえば Apache なら /var/www/html/index.html を用意すれば、ブラウザでサーバにアクセスしたときにその内容が表示される。
これらの場所や挙動を決めているのが設定ファイルだ。nginx は /etc/nginx/nginx.conf、Apache httpd は /etc/httpd/conf/httpd.conf にある。
Apache の設定ファイル内では DocumentRoot ディレクティブがドキュメントルートを指定している。ここを書き換えれば公開ディレクトリを別の場所（たとえば専用ユーザのホーム配下など）に変更できる。nginx では同じ役割を root ディレクティブが担い、server ブロックの中に書かれる。
設定ファイルの場所と、その中のどの項目が何を意味するかを押さえておくと、サイトの構成を自在に組み替えられる。
設定ファイルは複数のファイルに分割されていることもある。Apache では /etc/httpd/conf.d/ 以下に、nginx では /etc/nginx/conf.d/ 以下に、サイトごとの設定を分けて置く構成がよく使われる。
💾 なぜ触る前にコピーを取るのか
設定ファイルを編集するとき、ベテランが必ずやることがある。いつでも元へ戻せるよう、先にバックアップを取ることだ。
一行いじって動かなくなったとき、元の状態が手元になければ復旧に途方もない時間を取られる。だからこそ、これは現場の鉄則になっている。
たとえば sudo cp -a /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.origin のように複製しておく。-a を付けると所有者やパーミッションなどの属性を保ったままコピーできる。
設定ファイルはシステム領域にあるため、編集も root 権限が必要だ。vi や nano などのエディタを sudo 付きで開いて書き換える。
Apache でドキュメントルートを移す場合は、DocumentRoot の行と、対応する <Directory> ブロックのパスをそろえて書き換えるのがポイントだ。片方だけ直すとアクセスが拒否される。
✅ 反映する前に、文法は正しいか
設定を書き換えたら、サービスへ反映する前に必ず構文チェックを行う。これを怠ると、誤った設定のままサービスを再起動して、起動に失敗するという事故を招くからだ。
Apache には専用のチェックコマンドがあり、apachectl configtest を実行すると文法ミスの有無を調べてくれる。問題がなければ最後に Syntax OK と表示される。
なお ServerName を明示していないと AH00558 という案内（ドメイン名を自動設定した旨のお知らせ）が出るが、これはエラーではないので気にしなくて構わない。
もし誤りがあると、AH00526 のように「何行目に構文エラーがある」と具体的に指摘される。ただし指摘された行が実際のミス箇所とずれることもあるので、その前後もよく観察する。
nginx の場合は nginx -t が同じ役割を果たし、syntax is ok と test is successful の2行が出れば正常だ。
🔄 最後のひと押し reload で効かせる
構文チェックを通ったら、いよいよ設定を反映させる。Apache なら sudo systemctl reload httpd、nginx なら sudo systemctl reload nginx だ。
restart ではなく reload を勧めるのには理由がある。reload はサービスを止めずに設定だけ読み直すため、万一設定に問題が残っていても、それは反映されず従来の設定で動作を続けるので安全だ。
これに対して restart は一度サービスを止めてから起動し直すので、もし設定に誤りがあると停止したまま起動できなくなる恐れがある。確実に作り直したいときは restart を使うが、その場合も必ず構文チェックを通してから実行するのが鉄則だ。
ここで前の章の知識が効いてくる。設定ファイルを書き換えただけでは挙動は変わらず、reload か restart をして初めて新しい設定が効く、という点を忘れないでほしい。
反映後はブラウザで再読み込みするか curl http://localhost で、狙ったページが返るかを確かめる。
⚠ つまずいたら、まずこれ
ありがちな失敗は、index.html を置いたのにテストページのままになるケースだ。これはファイルの置き場所がドキュメントルートと食い違っているか、設定変更後に reload していないことが原因のことが多い。まず DocumentRoot の値と実際の置き場所が一致しているかを確認する。
逆に、設定上は正しいのにブラウザで「Forbidden」と出る場合は、ファイルのパーミッションや所有者、さらにRHEL系特有のSELinuxによるラベル制御が絡んでいることがある。
実務では、ドキュメントルートはホーム配下ではなく /var/www や /srv 以下に置くのが定番だ。ディレクトリは 755・ファイルは 644 程度に絞り、所有者はWebサーバの実行ユーザにそろえる。
設定変更は「バックアップ→編集→構文チェック→reload→ブラウザで確認」の順を毎回守ると、事故をぐっと減らせる。