Synology NAS 自架網站完整教學：Web Station、Docker、Caddy 反向代理與 Umami 實戰

一、Synology NAS 多網站架構是怎麼運作的？

如果只是架一個網站，事情其實很簡單；但當同一台 NAS 上開始出現 Boardgame、PhotoGallery、Blog 與其他 Web App，就需要把「使用者看到的網址」與「NAS 裡真正執行網站的位置」分開來看。

Internet
   ↓
網域 / DDNS
   ↓
Synology NAS
   ↓
HTTPS / Reverse Proxy
   ↓
Caddy（需要子目錄分流時）
   ↓
Web Station / Docker
   ↓
各個網站與資料庫

例如使用者可能只看到 example.com/boardgame/、example.com/photogallery/與 example.com/blog/，但 NAS 裡三個網站其實可以完全不同：Boardgame 可能只是由
Web Station 提供的靜態 HTML，PhotoGallery 是自行開發的 Docker Web App，而 Blog 則是
WordPress 搭配資料庫。

也就是說，公開網址只是入口，網站真正執行的位置可以完全不同。Reverse Proxy 與 Caddy 的工作，就是負責把外面的網址正確送到裡面的服務。

二、Web Station 與 Docker 分別適合什麼網站？

Synology Web Station 很適合處理較單純的網站，例如 HTML、CSS、JavaScript、圖片與其他靜態內容。像 Boardgame 這類以前端為主的網站，就可以直接由 Web Station 提供，不一定需要為了「全部 Docker 化」而額外增加 Container。

但 PhotoGallery 就完全不同。相簿除了顯示照片之外，還可能包含資料庫、EXIF、GPS、AI API、圖片處理、搜尋與管理後台，本質上已經是一套真正的 Web Application，因此比較適合放在 Docker 中執行。

WordPress 也是類似概念，它除了網頁程式之外，通常還需要 PHP、Web Server 與資料庫。使用 Docker 將不同元件彼此隔離，通常比把所有套件直接安裝在 NAS 系統中更容易維護。

簡單來說：Web Station 適合提供網站內容；Docker 適合執行網站程式。

三、Reverse Proxy 是什麼？為什麼架多個網站會需要？

Reverse Proxy 中文叫「反向代理」。名稱看起來很複雜，但其實可以把它想像成網站入口的櫃台。外面的使用者只需要知道網站的公開網址，至於請求進入 NAS 後應該送到哪一個 Web Application，則由 Reverse Proxy 負責判斷與轉送。

使用 Reverse Proxy 的好處包括統一 HTTPS、統一網域、管理多個網站，以及避免讓每一個 Docker服務都直接面向 Internet。Synology DSM 本身就有 Reverse Proxy 功能，因此如果網站架構單純，並不是一定需要額外安裝 Caddy。

四、為什麼 blog.example.com 通常不用 Caddy，但 example.com/blog/ 會需要？

這其實就是我後來加入 Caddy 的主要原因。假設有三個網站：

blog.example.com
photo.example.com
boardgame.example.com

這種是子網域（Subdomain）架構。每一個網站都有不同 Hostname，因此 Synology Reverse Proxy 很容易依照網域名稱判斷應該把流量送到哪一個網站。在這種情況下，DSM 本身的Reverse Proxy 通常就已經很好用，沒有必要為了分流而額外加入 Caddy。

但如果希望網站變成：

example.com/blog/
example.com/photogallery/
example.com/boardgame/

這種則是子目錄／子路徑（Subpath）架構。三個網站的 Domain 完全一樣，差別只剩下網址後面的/blog/、/photogallery/、/boardgame/。此時就需要更方便地依照 URL Path 進行分流。

example.com
   ↓
依 URL Path 判斷
   ├─ /blog/          → WordPress
   ├─ /photogallery/  → PhotoGallery
   └─ /boardgame/     → Boardgame

更精確地說，並不是「只有 Caddy 才能做到」，而是當網站大量使用 example.com/xxx/這種架構時，需要處理 Path Based Routing，而 Caddy 很適合集中管理這些規則。

因此可以簡化成一句話：如果網站使用 blog.example.com，Synology Reverse Proxy通常就夠；如果希望使用 example.com/blog/，就需要處理 URL Path 分流，而 Caddy
是一個很適合負責這件事的工具。

五、Caddy 與 Caddyfile 在整個架構中負責什麼？

Caddy 本身是一套 Web Server 與 Reverse Proxy 軟體，也可以處理 HTTPS、Redirect、Rewrite、Header 與網址路由。不過在 Synology NAS 的多網站架構中，可以把它定位成第二層網站路由器。

Internet
   ↓
Synology DSM
   ↓
Reverse Proxy / HTTPS
   ↓
Caddy
   ↓
依網址路徑分流
   ↓
各個網站

Synology DSM 可以負責面對 Internet、HTTPS 與憑證，Caddy 則專門判斷
/blog/、/photogallery/、/boardgame/
等路徑應該送到哪裡。

Caddyfile 則是 Caddy 的設定檔，用來描述不同網址、路徑、轉址與轉送規則。因為每個人的 Domain、Docker Network、網站架構與 Base Path都不相同，現在更實際的方式，是先理解自己要做 Path Based Routing，再利用 AI 依照自己的環境協助產生設定。

六、WordPress、PhotoGallery 與 Boardgame 如何共存在同一台 NAS？

理解前面的分工後，就會發現同一台 NAS 同時架不同技術的網站其實並不奇怪。Boardgame 可以是靜態網站，PhotoGallery 可以是自行開發的 Web App，Blog 則可以使用WordPress，而外部使用者仍然可以從同一個網域進入。

                     Synology NAS
                          │
                 Reverse Proxy / Caddy
                          │
          ┌───────────────┼───────────────┐
          │               │               │
     Boardgame       PhotoGallery        Blog
          │               │               │
     Web Station        Docker          Docker
                                          │
                                      WordPress
                                          │
                                       Database

這也是 Reverse Proxy 與 Caddy 最大的價值：前端網址可以統一，但後端完全不需要使用同一套技術。未來如果再新增新的網站，本質上也是建立新的 Web Station 或 Docker 服務，再新增對應的網址分流規則。

七、Umami：在自己的 NAS 建立網站流量分析

網站正式對外之後，下一個問題通常就是：到底有沒有人來看？我後來選擇使用 Umami 作為網站流量分析工具。它可以自行架設，也能同時分析多個網站，很適合在同一台 NAS 上同時經營 Blog、PhotoGallery、Boardgame 與其他網站的情況。

Umami 可以觀察訪客、Pageview、來源、國家、瀏覽器、裝置等資訊，也支援自訂 Event。實際使用後，我覺得 Event 對 PhotoGallery 特別有價值，因為「打開一張照片」和「真的停下來看、切換下一張、搜尋或分享」其實代表不同程度的使用行為。因此 Blog 可以偏重文章瀏覽，PhotoGallery 則可以觀察照片瀏覽與互動。這樣 Umami 就不只是單純的計數器，而是幫助理解網站實際使用方式的工具。

八、子目錄網站最容易遇到的問題

example.com/blog/ 這種架構雖然網址整齊，但通常比 blog.example.com更容易遇到設定問題。最大的原因是很多 Web Application 預設認為自己位於網站根目錄/，但實際上它可能位於 /blog/。

這時候可能出現 CSS、JavaScript、圖片找不到、API 404、登入後跳錯網址、Redirect Loop、Cookie 異常等問題。因此使用子目錄架站時，要特別留意 Base Path、Site URL、Absolute URL、Reverse Proxy、Redirect、Cookie Path 與 Forwarded Header。

其中 Base Path 特別重要，簡單來說，就是網站程式必須知道「我不是住在 /，而是住在 /blog/」。

Reverse Proxy 後面也可能涉及 Forwarded Header。有時候外部使用的是 HTTPS，但 Web Application接收到的內部連線並不是 HTTPS，如果程式沒有正確認出原始連線，就可能產生錯誤網址或不斷重新導向。某些即時功能還可能使用 WebSocket，因此也可能出現「網站可以開，但部分即時功能不能使用」的情況。

九、更新、備份與資訊安全注意事項

NAS 架網站最大的特色，也是最大的風險，就是網站伺服器與自己的重要資料可能位於同一台機器上。因此自架網站時最重要的原則不是「能不能架起來」，而是不要因為網站而把整台 NAS 暴露得太多。

基本原則包括網站統一使用 HTTPS、不需要公開的內部服務就不要直接面向 Internet、Database 不直接公開、管理介面盡量限制存取，DSM、Docker Image、WordPress 與 Plugin 也應定期更新。

Docker 方面則要記住：Container 是可以重建的，資料才是最重要的。真正需要保存的是資料庫、上傳檔案、網站資料、設定檔與環境設定。更新前也應先備份，再進行更新與測試，特別是 WordPress、Database 與 Plugin 之間可能存在版本相依性。

十、常見 500、502 錯誤與除錯觀念

自架網站很常看到 500 與 502，但兩者代表的方向並不相同。502 Bad Gateway 通常表示前面的 Reverse Proxy 還在，但它找不到後面的 Web Application，可能與 Container 未啟動、內部連線、Routing 或 Docker Network 有關。500 Internal Server Error 則通常表示 Request 已經成功到達網站，但網站程式本身發生錯誤，例如 WordPress、PHP、Plugin、資料庫、權限或程式本身出現問題。

因此看到錯誤代碼後，先判斷問題在哪一層，往往比直接重裝網站有效很多。理解整個 NAS 架站架構後，就可以依序判斷到底是 Domain、HTTPS、Reverse Proxy、Caddy、Docker 還是 Web Application 本身出問題。

十一、FAQ：Synology NAS 自架網站常見問題

Synology NAS 適合拿來架網站嗎？

如果本來就有 Synology NAS，而且網站流量不是非常巨大，用來架個人 Blog、攝影相簿、作品網站或小型 Web Application 很方便。不過 NAS 通常也存放重要資料，因此備份與安全性應該比一般測試主機更加重視。

Web Station 與 Docker 要選哪一個？

不是二選一。靜態 HTML、CSS、JavaScript 網站可以直接使用 Web Station；如果需要後端程式、資料庫或特殊執行環境，再使用 Docker。

Synology 已經有 Reverse Proxy，為什麼還要 Caddy？

如果網站使用 blog.example.com、photo.example.com 這類 Subdomain，Synology Reverse Proxy 通常就已經足夠；如果希望使用 example.com/blog/、example.com/photo/，所有網站共用同一個 Domain、只靠網址 Path 區分，就需要更方便的 Path Based Routing，這正是加入 Caddy 的主要原因。

一定要使用 Caddy 嗎？

不是。Caddy 是適合的工具之一，而不是 Synology NAS 架站的必要條件。只要架構簡單，完全可以只使用 Synology 自己的 Web Station 與 Reverse Proxy。

Caddyfile 是什麼？

Caddyfile 是 Caddy 的設定檔，主要描述網址要如何分流、轉送、Redirect 或 Rewrite。真正架設時可以依自己的環境利用 AI 協助產生，不需要先背設定語法。

為什麼 /blog/ 比 blog.example.com 難架？

因為 Web Application 不只要知道自己的 Domain，還要知道自己位於 /blog/ 這個 Base Path。網站內的 CSS、JavaScript、圖片、API、登入 Redirect 與 Cookie 都可能因此受到影響。

Umami 有什麼用途？

Umami 可以統一觀察多個網站的訪客與使用情況。除了 Pageview，也可以加入 Event Tracking，因此不論 Blog、PhotoGallery 或其他互動式網站，都能依需求設計分析方式。

結語：現在 NAS 架站真正應該學的是架構，而不是背指令

從最早的 Boardgame 靜態網站，到後來加入 PhotoGallery、WordPress Blog、其他 Web App 與 Umami，最大的心得是：網站愈多，真正重要的愈不是怎麼打一條指令，而是每一層到底負責什麼。

Internet
   ↓
Synology NAS
   ↓
HTTPS / Reverse Proxy
   ↓
Caddy（需要 Path Routing 時）
   ↓
Web Station / Docker
   ↓
網站與資料庫

再加上一套 Umami 負責網站流量分析。其中 Caddy 並不是所有 Synology NAS 都需要：如果使用blog.example.com 這種 Subdomain 架構，Synology Reverse Proxy 通常就已經足夠；但如果希望把不同網站整理成 example.com/blog/、example.com/photogallery/、example.com/boardgame/，就需要處理 URL Path 分流，而這正是 Caddy 很適合加入的位置。

現在 AI 已經可以協助產生 Docker Compose、Caddyfile 與 Reverse Proxy 的設定，因此公開教學更應該著重在：
我要架什麼、為什麼需要這個元件、它在整個架構中負責哪一層。
理解這些之後，不論未來增加第五個、第十個網站，底層原理其實都沒有改變。