Basic認証を.htaccessで掛けたら500エラーの原因と直し方｜お名前.comはAuthUserFileにドメイン名のフォルダが挟まる【2026年】

Basic認証を.htaccessで掛けて500エラーが出たとき、僕の会社で原因だったのはAuthUserFileに書いたパスでした。お名前.comのレンタルサーバーでは、public_htmlとページのフォルダの間に、ドメイン名のフォルダが1段挟まります。そこを入れたフルパスに直して、500は消えました。

2026年8月30日、社内向けのページに.htaccessでBasic認証を置いたとき、手元の古いメモにあったパスで書いて500になりました。同じ日には、Header setの命令も500の原因になり、使うのをやめています。

この記事では、500の原因の候補、フルパスの調べ方、.htpasswdの作り方、掛かったかを確かめる3点の確認を、記録に残した順に書きます。「パスなんて、どこを見れば分かるの？」で止まっている方は、フルパスの調べ方の章から読んでください。

Basic認証を.htaccessで掛けて500エラーになったら、まずAuthUserFileのパスを疑う

Basic認証の.htaccessで500が出たら、僕はまずAuthUserFileのパスを疑います。僕の会社で起きた500は、パスを正しいフルパスに書き直して直りました。

500 Internal Server Errorとは、サーバーが想定外の状態で要求に応えられなかったときの、まとめ役の応答です（MDN）。どの行が悪いかまでは教えてくれないので、.htaccessの中身から自分で絞り込みます。

Basic認証の.htaccessは、最小で4行です。伏せ字の部分は、自分のサーバーの値に置き換えます。

AuthType Basic
AuthName "Members Only"
AuthUserFile /home/<アカウント名>/public_html/<ドメイン名>/<ディレクトリ>/.htpasswd
Require valid-user

Apacheの公式文書では、AuthTypeで認証の方式を選び、AuthUserFileでパスワードのファイルの場所を指定します。Require valid-userは、そのファイルに載っている人なら誰でも通す書き方です。

AuthUserFileの値は、/から始まらないとServerRootを基準に読まれます（mod_authn_file）。.htaccessの場所が基準ではないので、/home/から始まるフルパスで書くのが確実です。

500エラーの原因の候補は4つ

500の原因の候補を、僕の会社の記録とApacheの公式文書から並べます。上の2つは僕の会社で実際に500が出たもの、下の2つは公式文書に書かれている決まりです。

僕なら、まずAuthUserFileのパスから見ます。Basic認証の4行のうち、サーバーごとに中身が変わるのはこの1行だけだからです。

お名前.comのレンタルサーバーで起きた500：旧メモのパスとドメイン名のフォルダ

2026年8月30日、僕の会社では社員向けの社外秘ダッシュボードを公開しました。置き場所はお名前.comのレンタルサーバー（RS）で、入口にBasic認証を掛けています。

最初のAuthUserFileは、手元にあったFTPのメモをもとに書きました。そのメモでは、公開フォルダがpublic_htmlの直下として記録されていました。そのパスのままだと、ページを開くと500になりました。

正しいフルパスは、public_htmlの下にドメイン名のフォルダが1段挟まる形でした。伏せ字で並べると、違いは1か所だけです。

# 500になった形（旧メモのパス）
AuthUserFile /home/<アカウント名>/public_html/<ディレクトリ>/.htpasswd

# 直った形（ドメイン名のフォルダが挟まる）
AuthUserFile /home/<アカウント名>/public_html/<ドメイン名>/<ディレクトリ>/.htpasswd

手がかりは、FTPの置き場所の記録にもありました。僕の会社の記録では、FTPでのアップロード先がドメイン名のフォルダから始まっています。FTPで見えるフォルダの並びと、サーバーの中の絶対パスは同じではありません。

同じ日の記録には、もう1つの500も残っています。検索に載せないために書いたHeader setの命令です。これも500の原因になったので使わず、noindexはページのmetaタグで入れることにしました。

このダッシュボードは、Basic認証の内側に1人1端末の登録を重ねた三重の守りにしています。守りの作りと応答の実測は社内ダッシュボードを自作して社員だけに見せる守り方に書いたので、ここではBasic認証の500に絞ります。

同じお名前.comのレンタルサーバーでは、.htaccessにPHPの実行の指定を書いて、PHPのソースが見えてしまったこともあります。.htaccessは「念のため」の1行が事故になりやすいファイルです。

その件は.htaccessのSetHandlerでPHPのソースが表示される原因に分けました。

記事を移したときの転送も、.htaccessに書きます。僕の会社で重なった記事を301で統合したときは、記事のフォルダにRedirectの行だけを置きました。

AuthUserFileのフルパスの調べ方：PHPで一時的に表示して、確かめたら消す

フルパスが分からないときは、そのフォルダに置いたPHPに自分の場所を表示させる方法があります。これはPHPの公式マニュアルで確かめられる一般的な調べ方で、8月30日の作業でこの方法を使った記録は僕の会社にはありません。

PHPの__DIR__は、そのファイルが置かれたフォルダの絶対パスを返します（PHPの公式マニュアル）。Basic認証を掛けたいフォルダに、次の1行だけのファイルを置いて、ブラウザで開きます。

<?php echo __DIR__;

表示されたパスの後ろに/.htpasswdを足したものが、AuthUserFileに書く値です。.htpasswdを別のフォルダに置くなら、そのフォルダで同じことをします。

$_SERVER['DOCUMENT_ROOT']でも、公開フォルダの位置は出せます。ただ公式マニュアルは、$_SERVERの値はWebサーバーが作るので、どのサーバーでも出るとは限らないとしています。

置いた場所そのものを返す__DIR__のほうが、取り違えが起きにくいです。とくに公開フォルダの奥に認証を掛けるときは、DOCUMENT_ROOTの後ろを自分でつなぐ手間もありません。

確かめ終えたら、そのPHPファイルはすぐに消してください。サーバーの中のパスには、アカウント名など外に見せる必要のない情報が入っています。手順書にパスを残すときも、アカウント名の部分は伏せ字にしておくと安心です。

.htpasswdの作り方：htpasswd -nbmで1行作り、置き場所を決める

パスワードのファイル（.htpasswd）は、僕の会社ではhtpasswd -nbmで作りました。画面に出た1行を.htpasswdとして保存し、Basic認証を掛けるフォルダに置いています。

htpasswd -nbm user <パスワード>
# 出力の例: user:$apr1$（以下、暗号化された文字列）

-nは結果をファイルに書かずに画面へ出す指定です。-bはパスワードをコマンドの中で渡す指定、-mはApache向けに手を加えたMD5で暗号化する指定です（htpasswdの公式文書）。

-mは2.2.18以降の既定なので、付けなくても同じ形式になります。公式文書は-B（bcrypt）を「現在はとても安全と考えられている」方式として載せているので、新しく作るならこちらも選べます。

-bには注意書きがあります。公式文書は、パスワードがコマンドラインにそのまま見えるので、扱いに十分注意するよう書いています。気になるなら-bを外し、パスワードを入力で聞かせる形にします。

置き場所について、Apacheの公式文書は、パスワードのファイルを公開フォルダの外に置くよう勧めています。守るフォルダの中に置くと、ファイルそのものをダウンロードされるおそれがあるためです。

僕の会社では同じフォルダに置き、.htpasswdを直接開くと404で返ることを確かめて使いました。Apacheの標準の設定で、.htから始まるファイルが拒否されていると読んでいます。

公開フォルダの外に置けるサーバーなら、外に置くほうが公式の勧めに沿います。同じフォルダに置くなら、後の章の3点の確認を省かないでください。

Header setでも500：IfModuleで囲んだHeader always setは通った

Basic認証と一緒に書いた別の命令が、500の原因になることもあります。2026年8月30日の記録では、Header setの命令が500の原因になったとして、使わないことにしました。

2026年9月10日には、別のデモページにもBasic認証を置きました。このときはnoindexのヘッダーを<IfModule mod_headers.c>で囲んで同居させました。

囲んだのはHeader always set X-Robots-Tagの1行です。この形では、Basic認証と同居させても500は出ませんでした。

そこで記録には、8月30日に500を出したのは、IfModuleで囲まないHeader setだった可能性が高いと残しています。同じ条件で並べて試してはいないので、断定はできていません。

公式文書を見ると、Headerの命令は.htaccessで使えますが、AllowOverrideでFileInfoが許されている必要があります（mod_headers）。許されていない命令は、そのまま500になります（core）。

IfModuleは、中の命令を、そのモジュールが読み込まれているときだけ有効にする囲みです。モジュールが無ければ命令ごと読み飛ばすので、500は避けられます。その代わり、ヘッダーが付かないまま静かに終わることもあります。

公式文書も、IfModuleはモジュールの有無に関係なく動く設定ファイルが要るときに使うもので、普段は要らないとしています。囲んで500が消えたら、curl -Iでヘッダーが本当に付いたかを見ておくと確実です。

noindexが目的なら、僕の会社のようにページのmetaタグで入れる方法もあります。.htaccessの行を増やさずに済むので、Basic認証の切り分けもしやすくなります。

Basic認証が掛かったかは401・200・403か404の3点で確かめる

Basic認証を置いたら、僕の会社では応答の番号を3つ確かめます。認証なしで401、正しいIDとパスワードで200、.htpasswdを直接開いて403か404です。

# 1. 認証なし → 401
curl -I https://example.com/<ディレクトリ>/

# 2. 正しいIDとパスワード → 200（パスワードは聞かれてから入力）
curl -I -u user https://example.com/<ディレクトリ>/

# 3. .htpasswd を直接 → 403 か 404
curl -I https://example.com/<ディレクトリ>/.htpasswd

-Iはヘッダーだけを取る指定で、-uはサーバーに渡すユーザー名とパスワードの指定です（curlの公式マニュアル）。ユーザー名だけを渡すとパスワードを聞いてくるので、コマンドにパスワードを書かずに済みます。

401は、有効な認証情報が無いときの応答です。どの方式で認証すればよいかを示すWWW-Authenticateのヘッダーと一緒に返ります（MDN）。

403は、サーバーが要求を理解したうえで断る応答で、認証し直しても結果は変わりません（MDN）。僕の会社の記録では、.htpasswdの直アクセスは404で返りました。

3つ目が200で返り、中身が見えたら危険です。すぐに.htpasswdを消すか公開フォルダの外へ移し、パスワードも作り直してください。

逆に、IDとパスワードを聞かれずにページが開くなら、.htaccessが読まれていない可能性があります。公式文書では、AllowOverrideがNoneだと.htaccessは読まれません。

Basic認証の命令には、AuthConfigの許可が要ります。レンタルサーバーでは自分で変えられないことが多いので、効かなければサーバー会社に問い合わせてください。

Basic認証だけで社外秘を守らない：HTTPSともう1枚の守り

Basic認証は、パスワードを暗号化せずに送る仕組みです。Apacheの公式文書も、大事なデータに使うならmod_ssl（HTTPS）と組み合わせるよう書いています。

僕の会社の社外秘ダッシュボードは、推測されにくいURLとBasic認証に、1人1端末の登録を重ねた三重の守りにしました。IDとパスワードが漏れても、登録していない端末では開けない作りです。

端末の登録の作り方と、応答を全パターンで実測した記録は、上でリンクした記事にまとめています。この記事で書いたBasic認証は、その三重の守りの入口の1枚です。

まとめ

• Basic認証の.htaccessで500が出たら、まずAuthUserFileのパスを疑う。/から始まるフルパスで書く
• お名前.comのレンタルサーバーでは、public_htmlの下にドメイン名のフォルダが1段挟まる形が正しかった（2026年8月30日の実測）
• フルパスは、そのフォルダに置いたPHPで__DIR__を表示すれば分かる。確かめたらファイルは消す
• 掛けた後は、認証なし401・正しいIDとパスワードで200・.htpasswd直で403か404の3点を確かめる
• 僕なら、Basic認証の4行だけでまず500が出ないことを確かめ、Headerなどの行はその後に1行ずつ足します