ドキュメントルートと設定ファイル
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サーバを起動するとテストページが表示されますが、実際に公開したいのは自分のコンテンツです。そこで知っておくべきなのが、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 です。reload はサービスを止めずに設定だけ読み直すため、万一設定に問題が残っていても、それは反映されず従来の設定で動作を続けるので安全です。これに対して restart は一度サービスを止めてから起動し直すので、もし設定に誤りがあると停止したまま起動できなくなる恐れがあります。確実に作り直したいときは restart を使いますが、その場合も必ず構文チェックを通してから実行するのが鉄則です。設定ファイルを書き換えただけでは挙動は変わらず、reload か restart をして初めて新しい設定が効く、という点を忘れないでください。反映後はブラウザで再読み込みするか curl http://localhost で、狙ったページが返るかを確かめます。
よくある失敗と実務の使いどころ
ありがちな失敗は、index.html を置いたのにテストページのままになるケースです。これはファイルの置き場所がドキュメントルートと食い違っているか、設定変更後に reload していないことが原因のことが多く、まず DocumentRoot の値と実際の置き場所が一致しているかを確認します。逆に、設定上は正しいのにブラウザで「Forbidden」と出る場合は、ファイルのパーミッションや所有者、さらにRHEL系特有のSELinuxによるラベル制御が絡んでいることがあります。実務では、ドキュメントルートはホーム配下ではなく /var/www や /srv 以下に置くのが定番で、ディレクトリは 755・ファイルは 644 程度に絞り、所有者はWebサーバの実行ユーザにそろえます。設定変更は「バックアップ→編集→構文チェック→reload→ブラウザで確認」の順を毎回守ると、事故をぐっと減らせます。