.htaccess 檔案是一個純文字的每目錄設定檔，Apache 會在每次請求到達該目錄樹時讀取它，並在請求被服務之前套用其中的 RewriteRule、Options 和 ErrorDocument 指令。若要在 Apache 伺服器中建立 .htaccess 檔案，您必須將檔案命名為完全符合 .htaccess（包含前置的點且沒有副檔名），將其放置在網站文件根目錄（或任何您想要覆寫的子目錄）中，確認主要 Apache 設定透過 AllowOverride 允許覆寫，並確保相關模組（如 mod_rewrite 和 mod_ssl）已載入。Apache 官方文件建議在您能控制虛擬主機設定時，將重寫邏輯放在虛擬主機設定中，僅在無法控制時才使用 .htaccess。由於該檔案會在每次命中其目錄的請求時被讀取，不正確的指令可能立即讓整個網站離線，因此安全的工作流程是產生一組範圍明確、可審核的指令、備份現有檔案、謹慎合併並在上線前於測試環境中測試。

how to create .htaccess file in apache server
how to create .htaccess file in apache server

.htaccess 在 Apache 2.4 內部如何運作

.htaccess 檔案是 Apache HTTP 伺服器支援的數個每目錄設定檔之一。預設情況下，Apache 會在任何處理請求的目錄中尋找一個檔名完全為 .htaccess 的檔案，向上遍歷目錄樹，並將每個符合的檔案合併至作用中的請求環境。此行為由主要伺服器設定中的 AccessFileName 指令控制，預設為 .htaccess，但若您的託管環境使用不同的慣例，可將其重新命名。該檔案為純文字，以 UTF-8 編碼（不含位元組順序標記），並在每次落於其目錄範圍內的請求時進行解析。

每目錄環境與虛擬主機環境的運作方式不同，因為 mod_rewrite 會套用符合該檔案所在目錄的 URL 前綴替換。這也是 Apache 官方文件建議在您能控制主要伺服器設定時將重寫規則放在其中、僅在無法控制時才使用 .htaccess 的原因之一。對於共享託管和受管的 Apache 環境，.htaccess 通常是個別網站擁有者能調整標準化、目錄列表或錯誤頁面、卻無需碰觸全域設定的唯一位置。

讓 .htaccess 生效前 Apache 伺服器所需條件

在 .htaccess 內的任何指令生效之前，主要 Apache 設定必須授予該檔案所需的權限。Directory 區塊中的 AllowOverride 指令決定了 Apache 允許從 .htaccess 套用哪些類別的指令。對於處理 HTTPS 標準化、停用目錄列表以及自訂 404 頁面的典型檔案，伺服器至少需要 AllowOverride FileInfo，而若您想使用 Options -Indexes，則需要 AllowOverride Options。若 AllowOverride 設為 None，Apache 會靜默忽略該檔案；若設為的類別未涵蓋您使用的指令，Apache 會傳回 500 Internal Server Error，而非部分套用該檔案。

相關模組也必須已載入。mod_rewrite 提供用於 HTTPS 標準化的 RewriteEngine、RewriteCond 和 RewriteRule 陳述式，而 mod_ssl 則讓 RewriteCond 能讀取 HTTPS 伺服器變數。在預設的 Apache 2.4 安裝中這些模組通常已存在，但共享託管偶爾會將其停用。您可在您能控制的伺服器上執行 apachectl -M 來確認，或請您的託管服務商確認 mod_rewrite 和 mod_ssl 已為您的帳號啟用。

.htaccess 中的指令 所需的 AllowOverride 類別 控制項目
RewriteEngine、RewriteCond、RewriteRule FileInfo 用於 HTTPS 標準化區塊的 URL 重寫
Options -Indexes Options 停用自動目錄列表
ErrorDocument FileInfo 提供本機自訂 404 文件

跨作業系統在本機建立 .htaccess 檔案

使用 .htaccess 的第一個實際障礙是檔名前置的點。大多數作業系統將以點開頭的名稱視為隱藏檔，因此一般的檔案管理員不會讓您直接將文件重新命名為 .htaccess。確切的解決方法取決於您的作業系統。目標是產生一個檔名完全為 .htaccess（其後沒有副檔名）、以 UTF-8 編碼（不含 BOM）、使用 LF 行尾結束符的檔案，然後再將其上傳至文件根目錄。

作業系統 方法 指令或步驟
Windows 命令提示字元 copy con .htaccess，輸入內容，按 Ctrl+Z 後按 Enter
Windows PowerShell New-Item .htaccess -Force，然後在您的編輯器中編輯
Windows 另存新檔對話方塊 將檔案以「.htaccess」（含引號）為名稱儲存
macOS 終端機 touch .htaccess，然後使用您偏好的編輯器編輯
macOS Finder 顯示隱藏檔，並將現有檔案重新命名為 .htaccess
Linux 終端機 touch .htaccess
Linux 文字編輯器 從您的編輯器將新檔案另存為 .htaccess

編碼很重要，因為在某些設定中，Apache 可能會拒絕以 UTF-8 BOM 或 Windows CRLF 行尾結束符儲存的檔案。Windows 上的 Notepad++ 可以寫入使用 Unix 行尾結束符的 UTF-8（不含 BOM）檔案，這是最安全的組合。一旦檔案為空或已包含您產生的指令，請將其上傳至您 Apache 網站的文件根目錄（依您的控制面板而定，通常是 public_html、htdocs 或 www 目錄）。請勿將 .htaccess 放在文件根目錄上層的父目錄中，否則 Apache 將不會讀取它。

使用 Htaccess Generator 產生範圍明確的 .htaccess

一旦解決了檔名問題，下一個問題就是該在檔案中放入哪些內容。手動撰寫 RewriteRule 模式容易出錯，因為主機名稱正則表達式必須跳脫每個點，HTTPS 條件會讀取 Apache 的 mod_ssl 狀態，而一個放錯位置的旗標可能會悄悄破壞每個重新導向。Htaccess Generator 會產生一個刻意精簡的 Apache 2.4 檔案，涵蓋三個文件根目錄任務：將每個請求重新導向至一個固定的 HTTPS 主機名稱、可選擇地停用自動目錄列表，以及提供本機自訂 404 頁面。

  1. 開啟 Htaccess Generator 並輸入精確的標準化來源，例如 https://www.example.com。輸入內容必須是不含認證資訊、連接埠、路徑、查詢字串或片段的 HTTPS URL，否則該工具會拒絕它。
  2. 僅選擇您託管環境允許的指令。保留固定主機的 HTTPS 重新導向，僅在您的網站允許 AllowOverride Options 時啟用 Options -Indexes，並提供以斜線開頭、指向現有檔案的本機 ErrorDocument 路徑。
  3. 檢閱產生的輸出。重新導向區塊使用 301 永久重新導向，在 RewriteCond 正則表達式中跳脫主機名稱的點，保留原始的 REQUEST_URI，並從 mod_ssl 讀取 HTTPS 變數。
  4. 複製或下載產生的檔案。在進行任何變更之前，先為現有的 .htaccess 建立一個帶有時間戳記的備份，以便在出問題時還原。
  5. 將新指令與現有檔案合併。若檔案中已包含 CMS 前端控制器規則、驗證、快取標頭或存取限制，請將重寫區塊新增至頂部，因為重寫邏輯通常需要在前端控制器路由之前執行。

上傳、備份並與現有規則合併

在上傳新檔案之前，請將運作中的 .htaccess 複製到一個帶有時間戳記名稱的安全位置，例如 .htaccess.backup-2026-07-17。以 ASCII 或文字模式透過 SFTP 上傳，以免檔案被重新編碼，在大多數環境中將權限設為 0644，並透過您的 FTP 用戶端確認遠端檔案名稱以點開頭。若新檔案取代了 WordPress、Joomla、Magento 或其他 CMS 使用的現有檔案，通常必須保留將請求交給 index.php 的前端控制器 RewriteRule，因此安全的做法是將標準化區塊插入 CMS 區段的上方，而非覆寫整個檔案。

現有的 CMS 檔案通常包含順序重要的驗證、deny-from-ip、快取控制和 gzip 指令。盲目地以新產生的檔案取代整個 .htaccess 可能會遺失驗證、暴露管理路徑，或使每個請求進入重寫迴圈。請逐行合併，保留原始的檔案結尾換行符，並避免更動您不了解的指令行。若您的託管服務商提供控制面板編輯器，您可以將合併後的內容貼入其中並儲存，但務必將備份保存在文件根目錄之外。

驗證 Apache 設定並執行測試環境測試

檔案就位後，請驗證 Apache 設定，而非僅依賴該檔案本身。在您能控制的伺服器上，執行 apachectl configtest 或 apachectl -t 以確認主要設定仍可解析，然後重新載入 Apache 使變更生效。在共享託管上，相當的做法是登入控制面板並使用面板提供的任何語法檢查或 Apache 狀態工具。一個語法上看似合理的 .htaccess 若使用了不允許的指令，仍可能與託管政策不相容。

請求 URL 預期行為
http://canonical-host/ 301 重新導向至 https://canonical-host/，保留原始路徑與查詢字串
http://alternate-host/ 301 重新導向至 https://canonical-host/，保留原始路徑與查詢字串
https://canonical-host/missing-page HTTP 404 狀態的本機 404 內容
https://canonical-host/private-dir/ 不顯示目錄列表；提供索引檔或傳回 403
https://canonical-host/page?q=foo 查詢字串在所有重新導向中保留

Curl 是這些測試最簡單的工具，因為它預設不會跟隨重新導向（除非您加上 -L），而且它會顯示原始的 Location 標頭，讓您能確認目的地。請測試上述的 HTTPS、HTTP、alternate-host 和 missing-page 情境，再加上幾個實際的頁面 URL，以確認 CMS 仍能正確路由。若任何請求傳回 500，代表標準化區塊參考了不支援的指令，因此請立即還原備份並檢查 Apache 錯誤記錄後再重試。

疑難排解 500 錯誤、迴圈與模組限制

上傳新的 .htaccess 後立即發生 500 內部伺服器錯誤，幾乎都代表以下兩種情況之一。第一種是您使用的指令所屬的 AllowOverride 類別未啟用；Options -Indexes 需要 AllowOverride Options，而 RewriteRule 加上 ErrorDocument 則需要 AllowOverride FileInfo。第二種是相關模組未載入；標準化區塊需要 mod_rewrite，而 RewriteCond 所依賴的 HTTPS 變數則需要 mod_ssl。請還原備份、查看 Apache 錯誤記錄中觸發錯誤的特定指令，然後若您有權限，請調整主設定中的 AllowOverride 類別，或從 .htaccess 中移除有問題的指令。

重新導向迴圈是另一個常見的失敗，通常屬於架構問題而非檔案本身的問題。HTTPS 條件會讀取 mod_ssl 狀態，因此若 TLS 在反向代理或負載平衡器終止，而 Apache 只看到純 HTTP，則規則會持續將請求視為非 HTTPS 而不斷重新導向。官方的 Apache mod_rewrite 介紹 文件說明了如何從受信任的代理讀取被覆寫的 X-Forwarded-Proto 標頭，但您應僅在完全掌控代理並了解偽造風險的情況下調整規則。更安全的替代做法是在代理或虛擬主機的 Redirect 指令中執行標準化，而不是放在 .htaccess 內。

若要使用本機自訂 404 頁面，請參考 Apache 自訂錯誤回應 文件，確認目標路徑存在且 Apache 具有 FileInfo 覆寫權限，否則錯誤回應本身可能會觸發錯誤迴圈。若 404 內容顯示 200 狀態，表示 ErrorDocument URL 被視為相對路徑，或目標檔案遺失。若遺失頁面的請求回傳預設的 Apache 錯誤頁面，則代表該目錄未啟用 AllowOverride FileInfo 類別，該指令被靜默忽略。

若要深入了解，請參閱 將 htaccess 轉換為 Nginx 設定：在重新載入前進行稽核。

若要深入了解，請參閱 如何在 cPanel 檔案管理員中建立 .htaccess 檔案。