自架 RSS 閱讀器推薦：VPS 資源消耗與功能比較

哪款自架 RSS 閱讀器適合小型 VPS

Miniflux 是適合部署在小型 VPS 上的自架 RSS 閱讀器。它僅由一個 Go 二進位檔搭配 PostgreSQL 組成。它支援 Fever 與 Google Reader API，因此可連接第三方手機應用程式，且升級僅需執行 docker compose pull。若您需要擴充功能，或是希望使用包含 SQLite 的單一容器，請選擇 FreshRSS。

有五款閱讀器值得佔用 VPS 磁碟空間：Miniflux、FreshRSS、CommaFeed、yarr 與 Tiny Tiny RSS。本頁比較了它們之間的實際差異：各堆疊所需的記憶體、強制使用的資料庫、手機應用程式所需的同步 API，以及升級時的處理方式。此處的每個數據皆由專案官方發布或經由簡單算術得出，文中會註明來源。這些數據並非針對您的硬體進行的基準測試，請使用 docker stats 自行測量您的伺服器。

五款閱讀器簡介

Miniflux 以 Go 語言編寫，並以單一靜態編譯的二進位檔案形式發布。其文件明確指出唯一的硬性依賴：它「僅能與 PostgreSQL 搭配使用」。該軟體不提供 SQLite 模式。它提供 REST API、Fever 相容 API 以及 Google Reader 相容 API，並支援 OPML 匯入與匯出。全文搜尋功能由 PostgreSQL 處理，這也是資料庫不可或缺的原因之一。

FreshRSS 使用 PHP 編寫，並以單一容器形式執行，同時包含網頁伺服器與應用程式。預設資料庫為 SQLite，無需額外服務；針對大型安裝環境，則支援 PostgreSQL 與 MySQL。它支援 Google Reader API 與 Fever API。安裝方式已於 FreshRSS 在 VPS 上的安裝指南 中說明，因此本頁面僅進行比較，不再重複安裝步驟。

CommaFeed 是基於 Quarkus 的 Java 應用程式，其版面配置模仿 Google Reader。其資料庫需在建置時決定，而非執行時，因此該專案針對不同資料庫發布個別映像檔：athou/commafeed:latest-h2 用於嵌入式 H2 資料庫，athou/commafeed:latest-postgresql 用於 PostgreSQL，另有 MySQL 與 MariaDB 的變體版本。它提供 REST API 與 Fever 相容 API。

yarr (yet another rss reader) 是一個內建 SQLite 的 Go 二進位檔案，完全不需要容器。執行 ./yarr 即可在 127.0.0.1:7070 監聽。其旗標簡潔：-addr 0.0.0.0:7070 -auth alice:secret 可將其開放至網路並設定密碼保護，-db /data/yarr.db 則可指定資料庫存放路徑。它具備 Fever 相容 API。其最新標記版本為 v2.8（發布於 2024 年 7 月，2026 年 8 月檢查），因此應將其視為已完成的軟體，而非持續開發中的專案。

Tiny Tiny RSS 是這五款軟體中歷史最悠久且執行負擔最重的一款。官方 Docker 設定包含四個服務：一個 PostgreSQL 容器、一個 PHP-FPM 應用程式容器、一個負責抓取訂閱源的獨立更新容器，以及前端的 nginx 容器。文件明確指出「此設定使用 PostgreSQL」。它擁有專屬的 JSON API，其 Android 客戶端及多個第三方應用程式均支援此 API。它不支援 Fever API。

每個堆疊所需的記憶體用量

以下數據為預算值而非實際測量值：這是每個堆疊在小型 VPS 上應維持的記憶體上限。CommaFeed 的數值為該專案官方發布的範例，將容器限制在 256 MB。其餘數值則是為訂閱擷取器（feed fetcher）預留空間後的上限，因為該元件在更新週期開始時會出現記憶體尖峰。

[
  {
    "label": "yarr (SQLite)",
    "containers": 1,
    "mem_limit_mb": 128
  },
  {
    "label": "FreshRSS (SQLite)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "CommaFeed (H2)",
    "containers": 1,
    "mem_limit_mb": 256
  },
  {
    "label": "Miniflux + Postgres",
    "containers": 2,
    "mem_limit_mb": 320
  },
  {
    "label": "Tiny Tiny RSS",
    "containers": 4,
    "mem_limit_mb": 640
  }
]

yarr 的需求最低，僅需 128 MB，因為它僅由一個二進位檔與一個 SQLite 檔案組成，背後沒有資料庫伺服器或語言執行環境。Miniflux 需在 2 個容器中分配 320 MB，其中大部分記憶體由 PostgreSQL 使用，而非 Miniflux 本身。Tiny Tiny RSS 則屬於特例，需在 4 個容器中分配 640 MB，因為應用程式、更新程式、資料庫與網頁伺服器是四個獨立的處理程序，各自擁有獨立的堆疊記憶體（heap）。

請將這些數值設定為實際限制，而非僅是期望值。Docker Compose 中的記憶體限制 一節涵蓋了相關語法，以及容器達到上限時的行為。若未設定限制，當伺服器記憶體耗盡時，容器不會優雅地失敗：核心會挑選一個處理程序並將其終止，而該受害者往往並非造成記憶體壓力的容器。

各閱讀器強制使用的資料庫

資料庫是這五款軟體在維運上最大的差異。這項決策比使用者介面的任何差異都更重要，因為它決定了您的備份程序與升級風險。

Miniflux 與官方的 Tiny Tiny RSS 設定皆要求使用 PostgreSQL。它能帶來真正的全文搜尋功能與安全的並發寫入。代價是需要額外的容器、儲存卷（volume），以及一個持續性的問題：官方的 PostgreSQL 映像檔無法在原地進行大版本間的資料遷移。Tiny Tiny RSS 文件對此有明確說明，並警告「官方 PostgreSQL 容器不支援大版本間的資料遷移」。您實際可行的選擇是鎖定舊的大版本，或是使用 pg_dump 與 pg_restore 進行匯出與匯入。請務必規劃每隔一兩年執行一次此程序。

SQLite 是 FreshRSS 與 yarr 的預設資料庫。它僅是一個檔案，無需伺服器、連接埠或密碼。對於單人使用且僅有數百個訂閱源的情況，其效能表現良好；但當多位使用者同時寫入時速度會變慢，這正是 FreshRSS 的 PostgreSQL 選項開始發揮價值的時候。yarr 在 v2.7 版本中加入了 PostgreSQL 支援作為選項，但內嵌檔案仍是其標準執行方式。

H2 是 CommaFeed 的預設內嵌資料庫，在開始使用前值得深思，因為 CommaFeed 在建置映像檔時就已決定了資料庫類型。日後若要從 H2 遷移至 PostgreSQL，並非單純修改設定檔即可完成。這需要更換不同的映像檔，並自行執行資料遷移，因此請在累積了一年的閱讀紀錄之前先做好決定。

手機應用程式是否可用

這個問題的影響比預期中更大，因為網頁介面僅是 RSS 閱讀器使用方式的一半。

Miniflux 支援 Fever 相容 API 與 Google Reader 相容 API，因此大多數 iOS 與 Android 客戶端皆可連接。FreshRSS 同樣支援這兩種 API，且其官方文件指出：Google Reader API 支援完整功能，表現「最佳」；而 Fever API 則「功能受限且效率較低」。FreshRSS 在應用程式登入前需執行兩個步驟：先在 Authentication 下啟用「Allow API access (required for mobile apps)」，接著在使用者個人資料中建立 API 密碼。若未設定 API 密碼，應用程式會出現驗證失敗，但網頁登入仍可正常運作，在釐清原因前這點容易造成困擾。

CommaFeed 與 yarr 僅提供 Fever 相容 API，因此僅適用於支援 Fever 的客戶端，不支援僅能使用 Google Reader API 的應用程式。Tiny Tiny RSS 則使用專屬 API，這意味著您必須使用專為其開發的客戶端。在匯入 300 個訂閱來源前，請務必確認您偏好的應用程式是否支援該閱讀器。

適用於 1 GB 記憶體伺服器的 Compose 設定檔

這是 Miniflux 堆疊，改編自該專案於 2026 年 8 月發布的 Docker 範例。公開的連接埠已綁定至 loopback 位址，監聽位址已明確設定，且兩個容器皆設有記憶體上限。

services:
  miniflux:
    image: miniflux/miniflux:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:8080"
    depends_on:
      db:
        condition: service_healthy
    environment:
      - DATABASE_URL=postgres://miniflux:CHANGE_ME@db/miniflux?sslmode=disable
      - LISTEN_ADDR=0.0.0.0:8080
      - BASE_URL=https://rss.example.com/
      - RUN_MIGRATIONS=1
      - CREATE_ADMIN=1
      - ADMIN_USERNAME=admin
      - ADMIN_PASSWORD=CHANGE_ME_TOO
      - POLLING_FREQUENCY=60
    healthcheck:
      test: ["CMD", "/usr/bin/miniflux", "-healthcheck", "auto"]
    mem_limit: 128m
  db:
    image: postgres:18
    restart: unless-stopped
    environment:
      - POSTGRES_USER=miniflux
      - POSTGRES_PASSWORD=CHANGE_ME
      - POSTGRES_DB=miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      start_period: 30s
    mem_limit: 192m
volumes:
  miniflux-db:

該檔案中有三行設定最容易出錯。LISTEN_ADDR=0.0.0.0:8080 必須設定，因為該二進位檔的預設值為 127.0.0.1:8080；若容器內的處理程序僅綁定至 loopback，則無法透過公開的連接埠存取，這會導致容器顯示為健康狀態，但連線卻被重設。磁碟區路徑 /var/lib/postgresql 適用於 PostgreSQL 18；版本 17 及更早版本將資料儲存於 /var/lib/postgresql/data，若掛載錯誤的路徑，資料目錄將不會位於磁碟區上，導致容器重建時資料遺失。127.0.0.1:8080:8080 可防止連接埠暴露於公用網際網路，因為若發布連接埠時未指定位址，Docker 會寫入一條 ufw 無法管理的規則。Docker 連接埠繞過 ufw 解釋了此機制，而 Traefik 反向代理 則是為其加上 TLS 的方式。

docker compose up -d
docker compose ps
docker compose logs -f miniflux
docker stats --no-stream

docker compose ps 應顯示兩個服務皆在執行中，且資料庫標記為 healthy。Miniflux 首次啟動時會記錄其結構遷移（schema migrations），這正是 RUN_MIGRATIONS=1 所觸發的動作。docker stats --no-stream 會列出即時記憶體使用量，此數值應與上述圖表中的上限進行比較。若 Miniflux 容器進入重啟迴圈，請閱讀其日誌：connect: connection refused 代表它在 PostgreSQL 準備好接受連線前就已啟動，這正是 service_healthy 條件所要防止的情況，請檢查該條件是否在編輯後仍保留。若您對 Compose 尚不熟悉，VPS 上的 Docker Compose 基礎 涵蓋了檔案配置的入門知識。

什麼東西無法在 1 GB 的伺服器上執行

Tiny Tiny RSS 是第一個該放棄的選擇。其官方的四個服務堆疊在 1 GB 的 VPS 上，前提是該 VPS 不能執行其他任何任務，且無法與其他依賴資料庫的應用程式及反向代理共存。四個服務代表四組額外負載，其中之一還是 PostgreSQL。

CommaFeed 可以執行，但必須使用 H2 映像檔並設定專案範例中指定的 256 MB 上限。在小型伺服器上最容易崩潰的組合是 JVM 搭配獨立的資料庫伺服器，因為 JVM 會佔用你留給它的所有剩餘記憶體。CommaFeed 的文件將 -Xmx256m 指為硬性限制，並將 OpenJ9 稱為「比 HotSpot JVM 更節省記憶體的替代方案」，這說明了它的記憶體消耗去向。

當伺服器記憶體耗盡時，核心的 out of memory killer 會挑選一個行程並將其終止。dmesg -T 會顯示類似 Out of memory: Killed process 1234 (java) 的訊息，而容器會直接從 docker compose ps 消失，且應用程式日誌中不會有任何紀錄，因為應用程式根本來不及寫入。

各項服務的升級行為

• Miniflux：docker compose pull && docker compose up -d，當設定 RUN_MIGRATIONS=1 時，會在啟動時自動執行資料庫結構遷移。升級風險不在於 Miniflux 本身，而在於其底層的 PostgreSQL 主要版本。
• FreshRSS：拉取新映像檔。若使用 SQLite，則無須升級資料庫引擎，常見的故障通常源自於未及時更新的第三方擴充功能。
• CommaFeed：拉取與您資料庫相符的映像檔版本。從 latest-h2 切換至 latest-postgresql 無法轉移既有資料。
• yarr：替換二進位執行檔並保留資料庫檔案。自 2024 年 7 月 v2.8 版本後未再發布更新（截至 2026 年 8 月檢查），通常無須升級。
• Tiny Tiny RSS：docker compose pull && docker compose up -d。資料庫結構遷移會自動執行，若需確認，介面會將您重新導向至遷移畫面。

請在執行上述任何操作前進行資料庫備份，而非事後才做。

docker compose exec -T db pg_dump -U miniflux miniflux | gzip > miniflux-$(date +%F).sql.gz

更新間隔對頻寬的影響

以下數據為算術推算，非實際測量值。假設有 100 個訂閱源，每個間隔對每個訂閱源發送一次請求，且每次回應大小為 40 KB。當伺服器支援條件式請求（conditional requests）時，實際流量會較低；若訂閱源包含全文內容，流量則會更高。

[
  {
    "label": "Every 5 minutes",
    "fetches_per_month": "864,000",
    "gb_per_month": 34.6
  },
  {
    "label": "Every 15 minutes",
    "fetches_per_month": "288,000",
    "gb_per_month": 11.5
  },
  {
    "label": "Every 30 minutes",
    "fetches_per_month": "144,000",
    "gb_per_month": 5.8
  },
  {
    "label": "Every 60 minutes",
    "fetches_per_month": "72,000",
    "gb_per_month": 2.9
  }
]

若 100 個訂閱源的更新間隔為 5 分鐘，每月請求數為 864,000 次，流量約為 34.6 GB。若改為每小時輪詢一次，請求數則為 72,000 次，流量約 2.9 GB。Miniflux 預設將 POLLING_FREQUENCY 設定為 60 分鐘，即該圖表的最後一行，此預設值適用於絕大多數使用者。頻繁請求並不會讓文章更早送達。

條件式請求能將實際流量維持在算術推算值之下。閱讀器若儲存了訂閱源回傳的 ETag 與 Last-Modified 標頭，後續請求時會將其作為 If-None-Match 與 If-Modified-Since 發送；若伺服器無新內容，則會回應 304 Not Modified 且不包含主體內容。此連線仍需進行握手，但省去了傳輸負載。若訂閱源忽略條件式請求，則每次都會回傳完整文件，因此少數大型訂閱源可能會佔用您大部分的傳輸配額。

過度頻繁的輪詢會導致被封鎖。若伺服器判定您正在進行惡意請求，會回應 429 Too Many Requests，部分網站則會直接回應 403。Miniflux 會將最後一次錯誤記錄在該訂閱源資訊中；若發現某個訂閱源停止更新而其他運作正常，請優先檢查訂閱源列表。

訂閱源會失效，OPML 檔案並非備份

訂閱源的失效速度比預期更快。網域過期、網站遷移至無訂閱源的平台，或是原本提供 XML 的 URL 轉而回傳 200 OK 狀態的 HTML 錯誤頁面。最後一種情況最棘手：請求成功但解析失敗，導致閱讀器記錄的是解析錯誤而非網路錯誤。建議每年將訂閱列表按最後更新時間排序，並刪除已停止更新的項目。

OPML 匯出檔僅包含您的訂閱清單，即訂閱源 URL 與資料夾名稱。它不包含閱讀狀態、星號標記、個別訂閱源設定、篩選規則或您儲存的文章內容。將此 OPML 匯入全新安裝的環境後，您會發現所有訂閱源都已恢復，但所有已讀文章都會被重新標記為未讀。

真正重要的備份是資料庫。對於 PostgreSQL，上述的 pg_dump 指令即為完整備份作業。若使用如 FreshRSS 或 yarr 等採用 SQLite 的閱讀器，請先停止寫入程序再複製檔案，或使用 sqlite3 yarr.db ".backup '/tmp/yarr-backup.db'" 在執行期間取得一致性的備份。直接對正在寫入的資料庫執行 cp 可能會產生無法開啟的損毀檔案，因為複製過程可能擷取到寫入一半的資料。請務必排程將這些檔案傳輸至伺服器外，這正是 VPS 上的 restic 備份 的用途，並至少在測試容器中執行一次還原，以確保程序可行。

訂閱閱讀器是自行架設成本最低的服務之一，這也是為何它出現在每一份 2026 年值得自架的服務 清單中。在旁邊部署 自架的 SearXNG 實例，讓您的閱讀與搜尋都維持在您掌控的硬體上。

FAQ

哪款自架 RSS 閱讀器佔用的記憶體最少？

yarr。它是一個編譯了 SQLite 的單一 Go 二進位檔，因此不需要額外的資料庫伺服器或語言執行環境，在 128 MB 的記憶體限制下即可順暢運作。其代價在於維護與功能：最新版本為 2024 年 7 月發布的 v2.8，且僅支援 Fever API。若您需要一個開發活躍且資源佔用相近的專案，Miniflux 搭配 PostgreSQL（約 320 MB）是更好的選擇。

我可以在 1 GB 的 VPS 上執行自架 RSS 閱讀器嗎？

可以。當您在兩個容器上設定 mem_limit 時，Miniflux 搭配 PostgreSQL 的佔用空間約為 320 MB，而 FreshRSS 搭配 SQLite 則可整合在單一容器中。在 1 GB 記憶體的環境下應避免使用官方的 Tiny Tiny RSS 堆疊，因為它包含 4 個服務（含其專屬的 PostgreSQL）。請務必設定記憶體限制，因為若容器在記憶體已滿的伺服器上未受限制，核心（kernel）會強制終止行程，且被選中的往往是資料庫而非導致問題的應用程式。

這些閱讀器中，哪些能與 iOS 和 Android 的 RSS App 搭配使用？

Miniflux 與 FreshRSS 同時支援 Fever 相容 API 與 Google Reader 相容 API，因此幾乎所有行動端客戶端皆可連接。CommaFeed 與 yarr 僅提供 Fever API。Tiny Tiny RSS 使用其專屬 API，因此您必須使用專為其開發的客戶端。在 FreshRSS 上，您必須在「驗證」（Authentication）設定中啟用 API 存取，並在個人檔案中設定獨立的 API 密碼，否則 App 將無法登入，即便網頁版功能正常亦然。

OPML 匯出檔可以作為 RSS 閱讀器的備份嗎？

不行。OPML 僅包含訂閱來源的 URL 與資料夾結構，因此它只能重建您的訂閱清單。閱讀狀態、星號標記、篩選規則與文章內容皆儲存在資料庫中。請務必備份資料庫本身，例如使用 PostgreSQL 的 pg_dump，或針對 SQLite 使用 .backup 指令，並將備份檔案移出伺服器。

Miniflux 支援 SQLite 嗎？

不支援。專案文件明確指出它「僅能與 PostgreSQL 搭配使用」，且全文搜尋功能是透過 PostgreSQL 的特性實作，因此沒有更輕量的模式可供切換。若您希望使用完全不需要資料庫容器的訂閱閱讀器，請執行預設使用 SQLite 後端的 FreshRSS，或是使用內建檔案儲存的 yarr。