htaccess 轉 Nginx 轉換器會將一個刻意精簡的 Apache .htaccess 指令子集，翻譯成可供檢閱的 Nginx 設定行，全程在您的 Mac 瀏覽器中執行，並針對每個條件或不支援的規則附上原始行號，而非自行猜測。工具會直接對應四種模式:支援的 RewriteRule(其方括號旗標列表為 L、R、R=301 或 R=302)、Options -Indexes、本機的 ErrorDocument 404 路徑，以及加上引號的 X-Robots-Tag Header set 值(會轉換為 add_header 行)。文件根目錄下 .htaccess 中的 Apache 模式，通常是在移除目錄前綴後對路徑進行比對，因此這類模式多半以插入符號開頭且沒有前導斜線;轉換器會為 Nginx 補上該前導斜線，因為 Nginx 的 rewrite 模式比對的是以 / 開頭的 URI。任何帶有條件、語法含糊或不熟悉的內容，都會停止該規則的轉換並回報，因為一條看似合理但實際不等價的 Nginx 設定行，比明確交由人工處理還要危險。輸出內容是一段設定片段，而非完整的 nginx.conf。您需要將其組裝到正確的 server 或 location 區塊中，備份目前線上的設定檔，執行 nginx -t，並在重新載入前先於 staging 環境測試。
Mac 瀏覽器設定:無需安裝，無需上傳
在 macOS 上開始移轉作業時，您不需要 Homebrew、不需要本機安裝的 Nginx，也不需要開啟終端機工作階段。htaccess 轉 Nginx 轉換器可在任何現代的 Mac 瀏覽器中執行，於本機處理您貼上的片段，且絕不會將輸入內容傳送至 Lizely。開啟 Safari、Chrome、Firefox 或 Arc，前往轉換器頁面，即可開始作業。若您在 Mac 上自行維護一個用於 staging 的開發用 Nginx，請保留一個獨立的終端機視窗，以便備份目前線上的設定檔，並在片段準備就緒後執行 nginx -t。macOS 上的本機 Nginx 通常透過 Homebrew 安裝，以 launchd 服務形式執行，並依架構不同，從 /opt/homebrew/etc/nginx/nginx.conf 或 /usr/local/etc/nginx/nginx.conf 這類路徑讀取設定。
在版本控管的資料夾中作業，是最安全的做法。將您的來源 .htaccess 片段儲存為 htaccess.txt，並放入移轉分支中，接著將焦點明確的幾行貼入轉換器，僅提交您已檢閱過的內容。轉換器不會爬梳您的網站、不會執行 Nginx，也不需要 AllowOverride 或檔案系統權限。請將它視為一個會產出草稿供人工檢閱的盤點輔助工具。
如何在 Mac 上將 htaccess 轉換為 Nginx:逐步工作流程
- 在 Mac 瀏覽器中開啟 htaccess 轉 Nginx 轉換器，將焦點明確的文件根目錄 .htaccess 片段複製到輸入區。請勿一次貼上整個舊版檔案。
- 點擊轉換，逐行閱讀輸出的結果。計算已轉換的行數與警告數量。
- 針對每個警告，記下結果中顯示的原始行號，接著開啟 Apache mod_rewrite 介紹與 Nginx rewrite 模組文件，以決定如何手動移轉該規則。
- 將輸出的片段以 nginx-fragment.conf 儲存於您的移轉資料夾中，以保留檢閱紀錄。
- 在具備語法高亮的文字編輯器中，開啟您真正的 nginx.conf 或其中一個 include 檔案。將每一行檢閱過的內容放到正確的位置:rewrite 規則與 error_page 屬於相關的 server 或 location 區塊內，而若您使用 add_header，則必須載入 headers 模組。
- 以含有時間戳記的副本備份目前線上的設定檔，接著在原地組裝該片段。在重新載入之前，請執行 nginx -t 以驗證組裝後的完整設定。
- 於 staging 環境，或在可回復的維護時段中，測試具代表性的請求。使用 curl -I 確認回應的 Location 標頭，而不要只依賴瀏覽器的網址列。
- 僅在測試組合通過後，才重新載入 Nginx。請保留備份檔案與開啟中的回復工作階段，直到確認正式環境流量運作正常。
轉換器會翻譯哪些內容，以及刻意略過哪些內容
支援的 rewrite 形式，恰好包含一條 RewriteRule，內含一個模式、一個替代字串，以及一個取自文件說明集合 L、R、R=301、R=302 的方括號旗標列表。Apache 的永久重新導向會對應為 Nginx 的 permanent 旗標，暫時重新導向會對應為 redirect，內部的 last 規則會對應為 last。文件根目錄下 .htaccess 中的模式，通常是在移除目錄前綴後對路徑進行比對，因此這類模式常以插入符號開頭且沒有斜線;轉換器會補上該前導斜線，因為 Nginx rewrite 模式比對的是以 / 開頭的 URI。這是一項文件化的範圍假設，並非適用於巢狀 .htaccess 檔、Alias 對應或 location 特定區塊的通用轉換。
| 所貼片段中的 Apache 形式 | 工具行為 | 在 Mac 上的下一步 |
|---|---|---|
| RewriteRule pattern sub [L] | 輸出為 last rewrite，並補上前導斜線 | 置於正確的 server 或 location 區塊中 |
| RewriteRule pattern sub [R=301] | 輸出為 permanent 重新導向 | 若情況允許，先以暫時旗標進行測試 |
| RewriteRule pattern sub [R] | 輸出為暫時重新導向 | 置於正確的上下文中並進行驗證 |
| 含 QSA、END、F、G、B、NC 等旗標的 RewriteRule | 附行號回報，不產生輸出 | 閱讀兩份手冊後手動移轉 |
| RewriteCond 後接 RewriteRule | 兩行都會回報，不產生輸出 | 重新評估變數、順序與 server 上下文 |
| 以單一短橫線作為替代字串的 RewriteRule | 附行號回報，不產生輸出 | 常與存取旗標搭配使用，需手動移轉 |
| Options -Indexes | 輸出為 autoindex off | 置於要保護的 location 內 |
| ErrorDocument 404 /404.html | 輸出為 error_page 404 /404.html | 依據 nginx core error_page 文件，置於相關的上下文中 |
| X-Robots-Tag Header set "value" | 輸出為 add_header X-Robots-Tag "value" | 在載入 headers 模組的前提下，置於正確的上下文中 |
RewriteCond 行絕不會自動轉換。Apache 的條件可檢查 HTTPS 狀態、主機名稱、檔案、目錄、查詢字串、標頭與擷取群組，且其評估順序與伺服器架構都很重要。當 RewriteRule 接在條件之後時，轉換器會一併抑制該規則，而不是輸出一條可能改變流量、造成迴圈或暴露路由的非條件式重新導向。以單一短橫線表示的 Apache 無替代字串目標，同樣會被保留不處理，因為它常會與改變存取或處理流程(但不變更 URI)的旗標搭配使用，而一個字面上的短橫線並非安全的 Nginx 替代方案。其他狀態碼、外部錯誤文件、條件式標頭、環境變數與指令容器，皆需要手動移轉。若要瞭解原始 Apache 規則的根本語意，Apache mod_rewrite 介紹是合適的起點。
從瀏覽器輸出，到 Mac 上可運作的 Nginx 設定檔
該片段不會建立 http、server 或 location 區塊，不會選擇 listen 連接埠，不會設定 server_name，不會設定 TLS，不會指定文件根目錄，不會保留 PHP 路由，不會設定反向代理，也不會定義記錄。一行設定即使語法正確，仍可能不適合其所處的上下文，因此上下文的選擇本身就是移轉工作的一部分。針對全站重新導向，請將 rewrite 規則置於 server 區塊;若規則僅針對部分路徑，則置於 location 區塊。由於 Nginx 的繼承行為與 Apache 的目錄走訪方式不同，add_header 必須置於實際負責回應的上下文中。
在 Mac 上，請於重新載入前以 nginx -t 進行驗證。該指令會讀取組裝後的設定、解析所有 include，並回報所發現的第一個語法錯誤或未知指令。若您使用 add_header 設定 X-Robots-Tag，請透過檢查 configure 參數中的 with-http_headers_module，確認已載入 headers 模組。若該模組未載入，該指令會在重新載入時失敗，您的 staging 測試也會回傳 500 錯誤。在 nginx -t 確認無誤後，請以 nginx -s reload 重新載入，並於 staging 環境以 curl -I 驗證具代表性的 URL。
永久與暫時重新導向:重新載入前的 Mac 檢查清單
永久重新導向值得格外謹慎處理，因為瀏覽器與中介層會將其快取。若情況允許，請先在受控環境中以暫時重新導向進行測試，待舊路徑、新路徑、查詢字串、替代主機與 HTTPS 行為皆測試無誤後，再切換為永久重新導向。請使用 curl -I 確認回應的 Location 標頭，而不是依賴瀏覽器的網址列，因為網址列可能會沿著一連串的重新導向跳轉，並隱藏最初的一跳。請至少為每條 RewriteRule 擷取一筆原始標頭，以保留完整的稽核紀錄。一次失敗的重新載入或重新導向迴圈可能讓公開網站離線，而一筆被快取的永久重新導向，即使在設定修正後，仍可能讓使用者停留在錯誤的路徑上。
何時應暫停使用轉換器，改為手動移轉
若來源片段包含身分驗證、授權、防止盜連、代理邏輯、CMS front-controller 規則或複雜條件，請將此次移轉視為工程工作，而非大量文字替換。Apache 與 Nginx 使用不同的請求處理模型。Apache .htaccess 是透過目錄被發現的，且可能被 AllowOverride 停用;Nginx 則是讀取集中式設定，並在 rewrite 處理前選擇 server 與 location 上下文。即使正則表達式完全相同，行為仍可能不同，因為被比對的字串、跳脫方式、查詢處理與迴圈行為皆有所差異。請將轉換器視為針對焦點片段的盤點輔助工具，手動處理每一個警告，將結果組裝至版本控管下的 Nginx 檔案，並於 staging 環境進行驗證。此工具不會假裝 .htaccess 的移轉只需單次貼上，這對任何在 macOS 或其他環境下的正式環境移轉來說，都是較為穩妥的立場。
若您在權衡各種選項，iPhone 上的 Meta Robots 產生器:Safari 工作流程對此有詳細說明。
若您在權衡各種選項，Android 上的 Nginx Config 產生器:瀏覽器工作流程對此有詳細說明。