Rewrite 與 .htaccess：從 NGINX 和 Apache 遷移至 ServBay Caddy 的差異與注意事項

背景資訊

URL Rewrite（通常亦稱為重寫或 URL 偽靜態），是一種在 Web 伺服器層動態修改請求 URL 的技術。它允許將使用者或搜尋引擎原本訪問的 URL（如 /?page=123）於伺服器內部重新導向為另一個 URL（如 /posts/123/），而使用者於瀏覽器地址欄看到的仍是重寫後的 URL。此技術廣泛應用於：

美化 URL 結構： 創造更易讀、易記且適合分享的「乾淨」或「漂亮」URL。
提升 SEO： 搜尋引擎更偏好結構清楚且具描述性的 URL。
隱藏內部實現細節： 避免外露檔案路徑或查詢參數，增強安全性。
統一 URL 格式： 強制要求特定的 URL 格式（如是否帶有 www、使用 HTTPS）。
實現路由功能： 現代 Web 框架普遍透過 Rewrite 將各請求導向單一入口檔（如 index.php），讓框架統一接管處理。

理解及設定 Rewrite 規則，是 Web 開發中的基本技能之一。

ServBay 對 NGINX 和 Apache 的支援

ServBay 內建並完整支援 NGINX 以及 Apache 作為 Web 伺服器。你可依專案需求或個人偏好，隨時切換預設 Web 伺服器。

如何切換預設 Web 伺服器，請參閱：如何設定預設的 Web 伺服器

ServBay 為開發者提供了 Caddy、NGINX 和 Apache 等多款主流 Web 伺服器選項。為簡化本地開發環境配置，ServBay 已針對 Caddy 及 NGINX 預設配置了常見的 Rewrite 規則，涵蓋大多數現代 Web 框架與 CMS 所需，這代表如 WordPress、Laravel、Symfony 等 PHP 應用，於 ServBay 下通常可直接運行、真正開箱即用，無需特別再設定額外的 Rewrite。

然而，若你平時習慣於 Apache 或 NGINX，並計劃將現有網站或專案遷移至 ServBay 內建的 Caddy，了解其在 Rewrite 規則配置上的差異就顯得格外重要。本文將說明 Apache、NGINX 與 Caddy 在 Rewrite 設定上的主要差異，並針對遷移過程中需注意之事項進行說明。

開箱即用的 Rewrite 規則：ServBay 的優勢

重要提示

ServBay 的設計理念之一，就是讓本地開發環境的建置與設定更為簡化。針對大多數主流 Web 應用與框架，ServBay 都已預設妥善的 Rewrite 規則配置。這意味著，在 ServBay 運行這些應用時，你基本上無需自行再撰寫或修改 Rewrite 規則，日常開發架構困擾已為你處理。

若你正將原先於 Apache 或 NGINX 環境運行的網站遷移至 ServBay Caddy，且需要處理較複雜的自訂 Rewrite 規則，建議參考下列詳細遷移指南：

Web 伺服器 Rewrite 規則簡介

不同 Web 伺服器在設計 Rewrite 規則時有各自特有的語法與檔案架構。理解這些差異，是跨伺服器遷移的基礎。以下將簡述 Apache、NGINX 與 Caddy 在 Rewrite 設定上的方式。

Apache 的 .htaccess 檔案

Apache HTTP Server 透過 .htaccess 檔案來設定 Rewrite 規則。.htaccess 是分散式設定檔，通常放於網站根目錄或特定子目錄中。它可於目錄層級覆寫主伺服器設定，對該層級下之所有目錄生效（若子目錄有自己的 .htaccess，則以子目錄為準）。Apache 主要透過 mod_rewrite 模組進行 Rewrite 控制。

基本用法舉例

以下為常見 .htaccess 範例，將所有不存在的檔案或資料夾請求重新導向至 index.php，多數 PHP 框架與 CMS 皆採此作為入口：

apache

# 啟用 Rewrite 引擎
RewriteEngine On

# 若請求的檔案或資料夾不存在則執行下一條 Rewrite 規則
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d

# 所有請求都重寫至 index.php，且保留查詢字串
RewriteRule ^(.*)$ index.php [L,QSA]

說明：

RewriteEngine On: 啟用當前目錄下的 Rewrite 功能。
RewriteCond %{REQUEST_FILENAME} !-f: 條件，判斷請求的路徑 %{REQUEST_FILENAME} 是否「不是」一個存在的檔案（!-f）。
RewriteCond %{REQUEST_FILENAME} !-d: 條件，判斷請求的路徑是否「不是」一個存在的目錄（!-d）。
RewriteRule ^(.*)$ index.php [L,QSA]: 具體的 Rewrite 規則。
- ^(.*)$: 匹配任何 URL 路徑。
- index.php: 匹配到的請求會重寫為 index.php。
- [L]: Last，代表若此規則符合即停止後續規則繼續匹配。
- [QSA]: Query String Append，會將原本查詢字串附加在重寫後的 URL。

NGINX 的 Rewrite 規則

NGINX 於主設定檔（nginx.conf）或網站設定檔（多位於 conf.d 或 sites-available/sites-enabled 目錄）配置 Rewrite。規則多設於 server（虛擬主機）或 location（路徑匹配）區塊。NGINX 具備強大的 ngx_http_rewrite_module，語法與 Apache 差異明顯。

基本用法舉例

以下為 NGINX 配置片段，實現將所有請求重寫至 index.php 之邏輯：

nginx

server {
    listen 80;
    server_name servbay.demo; # ServBay 範例域名

    root /Applications/ServBay/www/demo; # 網站根目錄

    # 依序嘗試檔案、目錄，皆無則重寫至 index.php
    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    # 處理 .php 請求，轉交 PHP-FPM/FastCGI
    location ~ \.php$ {
        # 確保檔案存在，避免任意檔案被執行
        try_files $uri =404;
        include fastcgi_params;
        # ServBay 下 PHP FastCGI 預設 Socket
        fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

說明：

location /: 匹配網站根徑之請求。
try_files $uri $uri/ /index.php?$query_string;: 常用指令，按此順序查找：
1. 請求的 URI 是否為檔案（$uri）。
2. 請求的 URI 是否為目錄（$uri/）。
3. 前兩者皆無則內部重寫至 /index.php，並保留查詢字串（?$query_string）。
location ~ \.php$: 使用正則表達式，匹配所有以 .php 結尾的請求。
fastcgi_pass unix:/Applications/ServBay/tmp/php-cgi.sock;: 依 ServBay 預設設定，轉發 PHP 請求至 PHP FastCGI 處理器。

Caddy 的 Rewrite 規則

Caddy 採階梯式設計的 Caddyfile 作為主要設定檔。Caddyfile 強調簡潔可讀，語法與 Apache、NGINX 大異其趣，卻更為直觀。Caddy 可透過 rewrite 指令與靈活多變的 Matcher 實現 Rewrite。

基本用法舉例

下例展示於 Caddyfile 中將請求重寫至 index.php 的寫法：

bash

servbay.demo { # ServBay 範例域名
    root * /Applications/ServBay/www/demo # 網站根目錄

    # 轉發 PHP 請求至 ServBay 預設 PHP FastCGI
    php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock

    # 提供靜態檔案服務
    file_server

    # 定義自訂 Matcher @notStatic：檔案、目錄皆不存在時觸發
    @notStatic {
        not {
            file {
                # 嘗試 {path} 檔案或 {path}/ 目錄，若皆不存在即成立
                try_files {path} {path}/
            }
        }
    }

    # @notStatic 成立時，將請求重寫至 /index.php
    rewrite @notStatic /index.php
}

說明：

servbay.demo { ... }: 定義站點區塊，適用於 servbay.demo。
root * /Applications/ServBay/www/demo: 設定網站根目錄，* 代表對所有路徑生效。
php_fastcgi unix//Applications/ServBay/tmp/php-cgi.sock: Caddy 內建指令，將所有符合 PHP 條件的請求自動轉交至 PHP FastCGI。ServBay 已幫你配置好。
file_server: 指示 Caddy 提供靜態檔服務，嘗試找出實體檔案或目錄。
@notStatic { ... }: 自訂命名 Matcher。
not { file { try_files {path} {path}/ } }: 判斷請求路徑 {path} 如無對應檔案或目錄時為真。
rewrite @notStatic /index.php: 若 notStatic 成立，則將請求內部重寫到 /index.php。

ServBay 的 Caddy 預設設定中，php_fastcgi 其實已內建類似 try_files 邏輯，同時新網站也都自動生成基本 Caddyfile，使大部分框架直接可用。上述範例僅說明 Caddy 原生語法實現同樣邏輯。

從 Apache 或 NGINX 遷移至 ServBay Caddy 的注意事項

將網站從 Apache 或 NGINX 遷移至 ServBay 的 Caddy，Rewrite 規則的轉換成為關鍵步驟。雖然 ServBay 已預設常見規則，但若專案中有大量自訂規則，仍需透徹理解並手動轉換。

務必詳讀以下遷移文件：

遷移過程需留意幾項主要差異：

Rewrite 規則語法及配置位置：
- Apache： 採 .htaccess 分散式設定（亦可集中於 httpd.conf/站點設定），規則以 RewriteRule 和 RewriteCond 指令為主，語法以正規表達式為主。
- NGINX： 集中於主設定檔（nginx.conf）或網站設定檔，規則多搭配 location、rewrite、if 及 try_files 使用，語法與 Apache 差異顯著。
- Caddy： 採 Caddyfile 集中式管理，規則以 rewrite 指令和多功能 Matcher（例如 file、path、header 等）實現，語法直觀。
- 轉換建議： Apache .htaccess 或 NGINX location/rewrite/try_files 規則需人工轉寫為 Caddyfile 語法。由於語法落差大，難以直接等價轉換，建議參考官方文檔，掌握 Rewrite 與 Matcher 的運作原理。
設定檔結構：
- Apache： 允許 .htaccess 於各層目錄自訂設定，或於主設定檔定義 VirtualHost。
- NGINX： 全部集中於 nginx.conf 及其包含檔案，透過 server 及 location 區塊組織。
- Caddy： 集中於 Caddyfile，站點以域名（如 servbay.demo）作為區塊，區塊內直接定義指令。Caddyfile 結構更扁平、易懂。
模組與指令對應：
- Apache、NGINX 均有眾多模組與指令。Caddy 功能同樣齊全，但名稱及用法上均有差異。舉例：Apache 的 mod_rewrite 在 Caddy 則以 rewrite 和 Matcher 實現，NGINX 的 try_files 在 Caddy 通常於 file Matcher 內部或 php_fastcgi 內建實現。
- 遷移時，需依據 Caddy 官方文檔，尋找對應指令與配置方式。
預設行為與優先順序：
- 各伺服器對請求、規則套用順序皆有各自機制。如 Apache 處理 .htaccess 的優先邏輯、NGINX location 優先級、Caddy 指令的順序處理等，均不可忽略。
- 遷移後強烈建議全面測試站點所有 URL，確保 Rewrite 行為與預期無誤。特別注意 ServBay Caddy 預設已內建許多必備 Rewrite，請避免重複書寫或規則衝突。

總結

ServBay 本地開發平台同時支援 Caddy、NGINX、Apache 三大 Web 伺服器。ServBay 已針對 Caddy 及 NGINX 預先內建大部分常用的 Rewrite，讓多數主流應用可直接部署、開箱即用。然而，若你習慣於 Apache 或 NGINX 自訂複雜設定並考慮遷移至 Caddy，認識各自 Rewrite 規則設計邏輯的差異極為重要。

Apache 著重於基於 .htaccess 與 RewriteRule 及 RewriteCond 的分散式配置，NGINX 採用集中設定檔與 location、rewrite、try_files，Caddy 則憑藉簡潔的 Caddyfile 及強大 Matcher 支援。

遷移重點在於正確將原有 Apache 或 NGINX Rewrite 規則轉譯為 Caddyfile 語法。雖然初期需要學習及調整，但 Caddy 的易讀結構、ServBay 便利的預設配置與詳細遷移教學，可大幅簡化你的遷移流程。希望本文有助你掌握關鍵差異，並於 ServBay 環境高效展開 Web 開發。

Rewrite 與 .htaccess：從 NGINX 和 Apache 遷移至 ServBay Caddy 的差異與注意事項 ​

開箱即用的 Rewrite 規則：ServBay 的優勢 ​

Web 伺服器 Rewrite 規則簡介 ​

Apache 的 .htaccess 檔案 ​

基本用法舉例 ​

NGINX 的 Rewrite 規則 ​

基本用法舉例 ​

Caddy 的 Rewrite 規則 ​

基本用法舉例 ​

從 Apache 或 NGINX 遷移至 ServBay Caddy 的注意事項 ​

總結 ​

Rewrite 與 .htaccess：從 NGINX 和 Apache 遷移至 ServBay Caddy 的差異與注意事項

開箱即用的 Rewrite 規則：ServBay 的優勢

Web 伺服器 Rewrite 規則簡介

Apache 的 .htaccess 檔案

基本用法舉例

NGINX 的 Rewrite 規則

基本用法舉例

Caddy 的 Rewrite 規則

基本用法舉例

從 Apache 或 NGINX 遷移至 ServBay Caddy 的注意事項

總結