htaccess 轉 Nginx 轉換器只會精準翻譯四種 RewriteRule 旗標組合與三種已記載的 Apache 指令，產生可供審閱的 Nginx 設定行，並針對每個條件、未知旗標或不支援的規則回傳帶行號的警告，而不會自行猜測。在 Android 上執行這項轉換與在桌面環境遷移時的情境不同，因為大多數人是在 Termux 內操作，而 Nginx 旁邊只有一個小型觸控螢幕編輯器、缺乏真正的終端機多工器，以及一個未必能妥善處理長段貼上文字的行動瀏覽器。因此 Android 工作流程是一連串聚焦的微編輯，而非單次大批貼上：在裝置上開啟原始的 .htaccess，複製一小段摘錄，透過瀏覽器在轉換器中執行，再將每行產出的 Nginx 設定讀回正確的脈絡中，然後在重新載入伺服器前驗證組合後的設定檔。將轉換器視為盤點助理而非一鍵翻譯工具，可以避免網站發生重新導向迴圈、URL 意外曝光，以及瀏覽器和 CDN 可能會鎖定數月之久的靜默快取污染。
為何在 Android 上轉換看起來不一樣
大多數已發布的 htaccess 轉 Nginx 指南都假設使用 Linux 筆電、SSH 存取以及舒適的螢幕。Android 同時改變了三件事。第一，編輯器通常是 Termux，搭配 nano 或 vim 以及觸控鍵盤，因此透過 pkg install termux-tools 與分享選單來複製貼上 200 行的摘錄，會比在桌面上更容易出錯。第二，Android 的瀏覽器沙箱更為嚴格：長段貼上可能會被截斷、自動完成可能會改寫引號字元，而剪貼簿權限在 Chrome、Firefox 與 Bromite 之間也有所不同。第三，典型的 Android 自架網站規模較小且為個人性質，因此幾乎不會有預備（staging）伺服器；正式的 Nginx 設定檔同時也是測試環境。
這種組合使得一款能產出可供審閱的設定行、每個問題發出一個警告、且完全不猜測重寫規則的轉換器，比一款會大量產出看似合理規則的工具安全得多。受支援的子集刻意保持精簡，才能讓結果在手機螢幕上仍可審核。任何落在該子集之外的內容（包括 RewriteCond、驗證區塊、proxy pass 以及 CMS front-controller 規則）都會以原始行號回傳警告，讓工程師自行決定如何處理。
貼上前先準備好 Termux 工作區
在開啟轉換器之前，請先設定好 Android 端，讓你能從實際的檔案複製文字，而非重新輸入。儘可能從 F-Droid 安裝 Termux，然後執行 pkg update && pkg install nginx nano termux-tools，讓編輯器與目標伺服器共用同一個 shell。Termux 內的 Nginx 將主要設定檔儲存於 /data/data/com.termux/files/usr/etc/nginx/nginx.conf，網站設定檔則位於同一前綴路徑下；可使用 nginx -V 查詢前綴路徑以找出實際啟用的區塊。你的 Apache 專案根目錄可能仍位於 /sdcard/ 下，Termux 可以讀取但無法寫入，除非執行 termux-setup-storage。
在 nano 中開啟既有的 .htaccess，標記出你打算遷移的精確行數（通常是最下方的 rewrite 區塊，加上位於其上方的任何 Options、ErrorDocument 與 Header 指令），並將該範圍明確的摘錄複製到剪貼簿。範圍明確的貼上非常重要：轉換器一次只解析一行，但若貼上 500 行混合條件、註解與不熟悉旗標的內容，會在六吋螢幕上產生一整片難以分流的警告。
在 Android 上將 htaccess 轉換為 Nginx
只要每個步驟都小到能在手機上閱讀，整套行動工作流程就能在一個專注的作業階段內完成。
- 在 Termux 中找到來源 .htaccess 檔案，例如 ~/sites/example.com/.htaccess，並僅挑出你希望遷移的 document-root 指令。驗證、proxy 與 location 專屬區塊應歸入人工工程筆記，而非轉換器的輸入內容。
- 複製一段聚焦的摘錄到剪貼簿。內容應包含 RewriteRule 行、任何 Options -Indexes、本地 ErrorDocument，以及你希望保留的所有 Header set X-Robots-Tag 行。
- 在 Android 瀏覽器中開啟 htaccess 轉 Nginx 轉換器。將摘錄貼入輸入區域並執行轉換。
- 依序閱讀輸出區域中每一行產出的 Nginx 設定。每行都是單一指令，目的是供審閱，而非盲目複製。
- 針對每個帶行號的警告，開啟對應的原始行，決定是要手動遷移，還是保留在 Apache，並在 Nginx 檔案中以註解記錄這個決定。
- 將保留下來的設定行合併到正確的 Nginx 脈絡中。大多數 document-root 的重寫應放入對應的 server { } 或 location / { } 區塊內；切勿將它們貼在 nginx.conf 的最上層。
- 執行 cp nginx.conf nginx.conf.bak-$(date +%s) 備份目前啟用的設定檔，以便在重新載入造成網站故障時能夠回復。
- 執行 nginx -t 驗證組合後的設定檔，再用 curl -I http://127.0.0.1/old-path 測試一個具代表性的請求，並在執行 nginx -s reload 重新載入前先確認 Location 標頭。
轉換器會對應的內容與仍須手動處理的部分
轉換器的合約範圍是有意受限的。它僅在 Apache 形式屬於受支援子集，且 Nginx 形式已記載於官方模組時，才會輸出指令。其他情況一律轉為警告，避免你靜默地改變了流量行為。更廣泛的相關界線討論（含貼上範例）請參閱 htaccess 批次轉 Nginx 參考指南。
| Apache 指令 | 典型範例 | Nginx 輸出 |
|---|---|---|
| RewriteRule pattern target [L] | RewriteRule ^about$ about.html [L] | rewrite ^/about$ /about.html last; |
| RewriteRule pattern target [R=301] | RewriteRule ^old$ /new/ [R=301,L] | rewrite ^/old$ /new/ permanent; |
| RewriteRule pattern target [R=302] | RewriteRule ^temp$ /new/ [R=302,L] | rewrite ^/temp$ /new/ redirect; |
| RewriteRule pattern target [R] (status 302) | RewriteRule ^go$ /new/ [R,L] | rewrite ^/go$ /new/ redirect; |
| Options -Indexes | Options -Indexes | autoindex off; |
| ErrorDocument 404 /path | ErrorDocument 404 /404.html | error_page 404 /404.html; |
| Header set X-Robots-Tag "value" | Header set X-Robots-Tag "noindex" | add_header X-Robots-Tag "noindex"; |
數種常見的 Apache 結構明確落在範圍之外，並會以原始行號產生警告：
- RewriteCond 行。條件會檢查 HTTPS 狀態、主機名稱、檔案、目錄、查詢字串、標頭與擷取群組。其評估順序與伺服器架構可能會改變語意，因此工具只會回報，而不會產生不安全的無條件規則。
- 未知旗標。QSA、F、G、B、NC、END 以及任何不在 L、R、R=301、R=302 集合內的旗標，都會中止該規則的轉換，因為 Nginx 並無一對一對應的選項。在做決定前，可至 Apache mod_rewrite 介紹 閱讀每個旗標的實際作用。
- 破折號（無替換）目標。獨立的「-」目標經常會與改變存取或處理方式（但不改變 URI）的旗標搭配使用。單純的破折號並非安全的 Nginx 對應，因此該規則會以警告形式保留不輸出。
- 其他狀態碼、外部錯誤文件、條件式標頭、環境變數與指令容器。這些都需要手動遷移至合適的 Nginx 脈絡。
正確解讀帶行號的警告
警告中包含三項資訊：你貼上內容中的原始行號、解析器所辨識到的 Apache 結構，以及不進行轉換的原因。請將警告視為待辦項目而非抱怨。針對每一項，開啟對應的原始行，判斷該規則在新網站中是否仍應保留，並從以下三種處理方式中擇一：手動遷移至正確的 Nginx 脈絡、因不再需要 Apache 專屬行為而予以刪除，或重建成真正的 Nginx 結構，例如 map、location 區塊內的 if，或專屬的 return。Nginx 核心 error_page 說明文件 是確認 error_page 404 接受相對 URI 並繼承請求方法的良好參考，而這有時與 Apache 的行為不同。內容為「RewriteCond not converted」的警告並不會阻擋其他輸出；其周圍所有受支援的行仍會產生，讓你能自行決定該條件的處理方式。
在 Termux 上重新載入前驗證 Nginx 設定
轉換器不會執行 nginx -t、不會檢查已安裝的模組，也不會讀取你的伺服器。這些工作必須由你在裝置上完成。將保留下來的設定行合併到正確的 server 或 location 區塊後，請將目前啟用的設定檔複製一份加上時間戳記的備份，執行 nginx -t 以顯示語法錯誤，僅在測試通過後再重新載入。接著以幾個具代表性的請求檢驗轉換結果：一個應該會重新導向的舊 URL、一個必須在重寫後存活的擷取反向引用、一個不應改變網址列的內部「last」規則、本地 404 路徑，以及任何 X-Robots-Tag 回應。請透過 curl -I 輸出中的 Location 標頭來確認，因為永久重新導向可能會被瀏覽器與中介層快取數月之久。先在可回復的維護時段內以暫時重新導向進行測試，待舊路徑、新路徑、查詢字串、替代主機與 HTTPS 行為皆如預期後，再改為永久重新導向。在公開的 Android 自架網站上若重新載入失敗，即代表一次真正的服務中斷，且能採取的回復手段有限，因此「先審核再重新載入」的模式並非可有可無。
若你在評估其他選項，免註冊的免費 Nginx 設定產生器：使用方式 對此有更詳細的說明。