在 iPhone 上的 Nginx 設定檔產生器，是一款基於瀏覽器的工具，能為靜態網站或單頁應用程式產生一個可供稽核的伺服器區塊，完全在 iOS 的 Safari 或 Chrome 中執行，無需安裝應用程式或建立帳號。產生的區塊會監聽 IPv4 與 IPv6 的 80 連接埠，選取一個精確的 server_name，宣告一個絕對路徑的 POSIX 文件根目錄，並套用一個有界限的靜態資產快取（可選擇 gzip），所有內容皆由工具驗證過的輸入組裝而成，絕不會誤讀。因為所有轉換都在瀏覽器中進行，所以你的網域、根目錄路徑與快取時間完全不會離開裝置。

行動工作流程之所以重要，是出於實際考量。許多小型靜態來源——登陸頁、說明文件網站、行銷單頁、SPA 外殼——是由手邊只有手機的人在設定，特別是在出差、晚上，或是在僅存在一個下午的測試主機上。一個基於瀏覽器的 Nginx 設定檔產生器正能填補這個空缺，它提供一個可供檢視的單一片段，讓你複製、AirDrop、寄電子郵件，或推送到雲端檔案，然後在實際伺服器上用 nginx -t 進行驗證。

nginx config generator on iphone
iPhone 上的 Nginx 設定檔產生器：行動工作流程

此工具在 iPhone 瀏覽器中的功能

當你在 iOS Safari 或 Chrome 中開啟此工具時，輸出會是一個保留在瀏覽器中供檢視與傳輸的伺服器區塊。產生器會驗證每個欄位，從允許的指令組裝出一個固定的 HTTP 伺服器區塊，而且絕不會試圖成為通用的 Nginx 編輯器。它刻意縮小了輸入範圍，這樣在行動裝置上輸入的內容——使用虛擬鍵盤輸入、常是單手操作、有時是在移動中——就不會意外將分號、變數、大括號、類似 shell 的語法或額外的伺服器區塊帶入輸出。

輸出會保留在瀏覽器分頁中。它不會被送到遠端服務，也不需要登入。這讓 iPhone 工作流程成為真正的「檢視—傳輸」循環：輸入、產生、閱讀指令、複製區塊、交付給伺服器。

產生器會接受與不會接受的輸入

產生器會拒絕具有設定檔形式的輸入，確保你在輸出中看到的內容就是該伺服器區塊的完整設定表面。具體來說，適用以下規則：

  • 網域：一個精確的 server_name，沒有通訊協定（無 http://）、沒有萬用字元、沒有正規表達式。如果你需要 www 與頂網域，或多個別名，產生器不會為你推斷；請在其他地方設計。
  • 文件根目錄：由一組有限的、安全的路徑字元所組成的絕對 POSIX 路徑。分號、大括號、變數、空白字元與類似 shell 的語法都會被拒絕，以防止路徑夾帶額外的指令。
  • 快取時間：介於 1 到 365 天的整數，搭配 expires 與 Cache-Control public 用於資產位置。
  • 回退模式：要麼是真正的靜態 404，要麼是將未知路徑重寫至 /index.html 的 SPA 回退。此選擇是刻意且互斥的；此工具不會同時啟用兩者。
  • Gzip：一個可選的開關，會啟用標準的 filter，加入 Vary: Accept-Encoding，並列出 CSS、JavaScript、JSON 與 SVG 等類型。

由於回退選擇會改變遺漏路徑的處理方式，因此在按下「產生」之前值得仔細比較：

面向 靜態網站（真正的 404） SPA 回退至 /index.html
使用情境 純 HTML、說明文件、行銷頁面 React、Vue、Svelte 或類似的用戶端渲染應用程式
像 /missing 的未知 URL 透過 try_files =404 回傳 Nginx 預設的 404 回傳 200 並附上應用程式外殼
對遺漏資產的 SEO 影響 誠實的 404 訊號可被檢索並取消索引 損壞的連結可能會偽裝成有效頁面
在錯誤的網站上啟用的風險 低——保留錯誤語意 高——隱藏損壞的 URL 並扭曲錯誤回報

如果你想了解特定技術棧背後的快取控制與 gzip 類型的實際數字，Nginx 設定檔產生器指令與限制速查表會逐步說明產生器輸出的確切指令表面，以及它與手寫正式環境區塊的差異。

如何逐步在 iPhone 上建立 Nginx 設定檔

在手機上，這個循環比在筆電上更短，所以每個步驟都需要謹慎。以下順序在 iOS 的 Safari 或 Chrome 中運作良好：

  1. 在 iPhone 瀏覽器中開啟 Nginx 設定檔產生器，並視需要旋轉為橫向以取得更多水平空間。
  2. 在伺服器名稱欄位中輸入一個精確的網域，不要加通訊協定，也不要加結尾斜線。確認拼字正確——沒有萬用字元可以補救錯字。
  3. 輸入絕對的文件根目錄，例如 /var/www/example.com/html。確保路徑使用正斜線，且僅包含工具接受的安全字元。
  4. 挑選介於 1 到 365 天的快取時間。僅當你的資產帶有指紋或版本編號時才使用較長的值；否則訪客在部署後可能會繼續取得過時的檔案。
  5. 決定回退方式。僅當用戶端路由確實應該接收未知的應用程式路徑時，才啟用 SPA 回退。對於一般的內容網站，請將其關閉。
  6. 如果你的文字資產能受益於 gzip，且你沒有將機密資訊反映到壓縮回應中，則開啟 gzip；否則將其關閉。
  7. 點選「產生」並在小螢幕上逐行閱讀產生的區塊。將 listen 連接埠、server_name、root、try_files、資產位置以及可選的 gzip 段落與Nginx 核心模組說明文件以及Nginx gzip 模組說明文件進行交叉核對。
  8. 使用 iOS 分享選單將區塊複製到剪貼簿、傳送至「備忘錄」、「郵件」或雲端檔案，或透過 AirDrop 傳送到 Mac。
  9. 在伺服器上，將檢視過的檔案放入有效的 Nginx include 鏈中（通常為 /etc/nginx/conf.d/ 或 sites-enabled 路徑），然後進入測試階段。

將檔案從 iPhone 移至 Nginx 伺服器

產生的區塊會留在手機上，直到你將其傳輸出去。常見的 iPhone 到伺服器的路徑包括：

  • 複製到剪貼簿，再貼到伺服器：當你已經在桌面終端機中開啟一個 shell，並透過 SSH 將區塊貼到檔案中時適用。
  • 寄送電子郵件或訊息給自己：當稍後才會連到伺服器時很實用，因為該區塊會是一段純文字工件，你可以在 heredoc 中引用。
  • 雲端硬碟：將文字上傳至 iCloud Drive、Dropbox 或私有儲存桶，然後在伺服器上使用 curl 或 wget 將其擷取至設定目錄。
  • iPhone 上的 SSH 應用程式：像 Termius 或 Prompt 之類的工具可讓你直接在伺服器上編輯檔案。手機螢幕雖小，但對於單一區塊來說，heredoc 貼上仍然可行。

無論採用哪種方式，該檔案都應落在伺服器上正確的 include 上下文中。除非這是你的文件化慣例，否則不要將其貼到 nginx.conf 的頂層；放在 conf.d/ 或 sites-enabled/ 下的小片段通常是合適的位置。

測試設定檔：nginx -t 與實際請求

一旦區塊就位，驗證步驟會發生在伺服器端，而非 iPhone 上。最起碼應負責任地執行以下順序：

  1. 在進行任何變更之前備份有效的設定檔——例如 cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak——並記錄有效的 include 鏈。
  2. 對完整設定檔執行 nginx -t。通過的結果僅能證明語法有效且參考的檔案存在；它無法證明檔案權限、DNS 解析、路由行為、憑證涵蓋範圍或實際回應品質。
  3. 使用 curl -I 測試標頭，使用 curl -v 測試主體，測試具代表性的請求：首頁、靜態資產、未知 URL（以確認 404 還是 SPA 外殼），以及若 gzip 開啟時的壓縮回應。
  4. 當你的平台程序支援時，請使用重新載入而非突然停止服務。遵循如何在不停機的情況下讓 Nginx 重新載入設定中的重新載入程序，可在套用新設定的同時保持現有連線不中斷。
  5. 若 nginx -t 失敗，請不要重新載入。若重新載入後請求失敗，請還原備份並閱讀錯誤記錄，然後再進行下一次迭代。

請將通過的 nginx -t 視為一道關卡，而非證明。iPhone 端產生了一個語法上乾淨的片段；伺服器端仍須證明權限、擁有權、DNS 以及實際的回應形狀與訪客將看到的內容一致。

此工具在 iPhone 或其他任何地方未包含的內容

產生器刻意僅產生靜態網站片段。下表明確列出其範圍，讓你知道你仍需在其他地方新增或設定哪些內容：

包含在產生的區塊中 刻意排除
listen 80 IPv4 與 IPv6 TLS listen 443、憑證路徑、HSTS
一個精確的 server_name 萬用字元、正則表達式、www 重新導向、替代主機
絕對 POSIX 根目錄與 index PHP-FastCGI、反向代理上游、WebSocket
用於靜態或 SPA 回退的 try_files 驗證、速率限制、自訂錯誤頁面
含 expires 與 Cache-Control 的資產位置 記錄指令、安全標頭、MIME 包含路徑
含 Vary 與類型的可選 gzip filter 預先壓縮資產處理、壓縮側通道調校
瀏覽器端的輸入驗證 伺服器端對路徑存在性、擁有權、SELinux、讀取權限的檢查

這些排除並非疏漏。TLS 取決於憑證路徑、更新工具、支援的通訊協定、重新導向、代理或 CDN 拓樸以及 HSTS 政策，憑空編造這些內容會造成虛假的安全感。請透過託管平台或經過檢視的伺服器程序來設定 HTTPS，然後分別測試 HTTP 到 HTTPS 的行為。

當行動裝置產生的設定檔不敷使用時

iPhone 的工作流程只有在實際部署範圍與其狹窄的設定範圍相符時，才會產生正確的產物。若您的情況包含下列任何一項，即使在手機上執行沒有問題，從產生器開始仍然是錯誤的起點：

  • 代管主機控制面板，其設定介面位於供應商 UI 中，而非手動編輯的伺服器區塊。
  • 容器或 Kubernetes ingress，其中 Nginx 通常是 sidecar 或具備自身 ConfigMap 慣例的 ingress controller。
  • 由 CDN 置於前端的來源伺服器，大多數的路由與快取決策都發生在邊緣，Nginx 僅扮演小型上游角色。
  • 應用程式後端含有 FastCGI、gRPC、WebSockets、上傳、驗證、速率限制或自訂錯誤頁面，而這些刻意未包含在該片段中。
  • 多虛擬主機伺服器，其中單一主機的產生器無法模擬跨多個名稱的路由、憑證涵蓋範圍或重新導向政策。

對於上述所有情況，iPhone 仍然非常適合用來草擬與檢視小型伺服器區塊，但該區塊需要在更大、更具部署特定性的設定中加以延伸。 最易於維護的成果，是與當前部署證據相符的最小且經過審閱的設定檔 —— 當部署確實為靜態來源時，手機產生的靜態網站片段正好符合這個條件。