Fess 自架搜尋伺服器：以 OpenSearch 為底、用瀏覽器介面取代搜尋引擎調校
Open-source, self-hosted enterprise & site search server built on OpenSearch. Crawls web / file / DB / cloud sources, 20+ languages, REST API, and AI/RAG & semantic search. Apache-2.0.
秒懂
- 它是什麼？
- Fess 是一個以 Java 撰寫、Apache-2.0 授權的自架企業搜尋伺服器，內建網頁、檔案系統與資料庫爬蟲，並以瀏覽器管理介面取代直接操作 OpenSearch。本文拆解它的抓取與檢索流程、安裝路徑、真實限制，以及它與直接使用 OpenSearch 的差異。
- 適合誰用？
- 如果你需要的是讓非工程背景的同事自行新增爬取目標、設定排程、用 LDAP 或 SAML 登入並依角色過濾結果，Fess 的瀏覽器管理介面省下的整合工時通常超過它帶來的維運負擔，值得採用。若你只需要對既有索引做低延遲的客製查詢，或已經有一套成熟的 OpenSearch 索引設計與用戶端程式，Fess 反而多了一層要維護的抽象。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 1 天前。
- 用什麼語言寫的？
- 主要是 Java（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Fess 要解的不是查詢速度，是「誰來設定爬取」
多數搜尋引擎的瓶頸不在查詢，而在把哪些內容餵進索引。OpenSearch 本身不會去爬網站、不會讀共享資料夾裡的 Office 文件、也不會定期從關聯式資料庫拉資料列。要補上這一段，團隊通常得自己寫爬蟲、處理文件格式轉換、設計索引映射、再寫一套權限過濾邏輯。Fess 把這一整段包成產品：README 說明它內建爬蟲，可從網站、檔案系統與資料庫或 CSV 等資料存放區收集文件，並支援 Microsoft Office、PDF 與 ZIP 壓縮檔等多種格式。
它的目標讀者因此不是搜尋工程師，而是需要交付一個可用搜尋入口的 IT 或內部系統團隊。README 明確寫道，Fess 雖然建構在 OpenSearch 上，但不需要事先具備 OpenSearch 知識，設定透過瀏覽器管理介面完成。這句話同時定義了它的價值與它的天花板：把檢索系統的操作介面化，換取更低的導入門檻，代價是底層調校的自由度被收斂。
另一個容易被忽略的使用場景是對外網站搜尋。專案提供 Fess Site Search，README 稱其為 Google Site Search 的免費替代方案，並指向 FSS JS Generator 的說明文件。這代表同一套伺服器可以同時服務內部知識庫與公開網站的搜尋框。
抓取、索引、查詢：三個階段各自對應到哪個元件
從 README 與專案結構可以看出，Fess 的資料流分成三段。第一段是爬取：你在管理介面的 Web、File 或 Data Store 設定頁註冊抓取目標，接著到 Scheduler 頁啟動排程。爬蟲依設定把來源文件取出，經過格式解析後寫入 OpenSearch。第二段是索引與分析：Fess 支援 20 種以上語言的介面與文字分析，這部分依賴 OpenSearch 的分析器鏈。第三段是查詢：使用者在搜尋介面送出查詢，Fess 產生查詢、套用角色與權限過濾，再回傳含 facet、排序與搜尋建議的結果。
權限過濾是這個架構裡最實務的一段。README 把它列為獨立功能：以角色與權限為基礎過濾搜尋結果，並支援 LDAP、OpenID Connect、SAML、SPNEGO 與 Microsoft Entra ID 的單一登入。這表示過濾條件不是在應用層事後篩掉，而是與查詢一起送進檢索後端。實際的欄位與映射方式在 README 中沒有交代，需要查閱官方文件。
擴充點分為三類，README 分別列出：資料存放區連接器（fess-ds-* 系列，涵蓋 Confluence/Jira、Box、CSV、Database、Dropbox、Elasticsearch、Git、Gitbucket、G Suite、JSON、Office 365、S3、Salesforce、SharePoint、Slack）、擷取流程外掛（Logger、NDJSON）、以及腳本外掛（Groovy、OGNL）。主題則由獨立的 fess-themes 專案提供，README 描述每個主題是自帶的單頁應用，以在管理介面上傳 ZIP 的方式安裝。這個設計意味著前端客製不必重新編譯 Java 專案。
安裝路徑有三條，選錯會多花半天
README 提供三種發行格式：DEB、RPM 與 ZIP。ZIP 的流程是解壓後進入目錄執行啟動腳本：
$ unzip fess-<version>.zip $ cd fess-<version> $ ./bin/fess
啟動後搜尋介面在 http://localhost:8080/，管理介面在 http://localhost:8080/admin/，README 標明預設帳號密碼為 admin/admin。首次登入後應立即更換，這組預設值在對外可達的環境等同於沒有認證。
Docker 映像發佈在 ghcr.io，Compose 檔案放在 docker-fess 專案的 compose 目錄下。這裡有一個容易踩到的差異：README 指出 Docker 映像已內含 OpenSearch，其他安裝方式則需要自行準備。也就是說走 ZIP、RPM 或 DEB 的人，在啟動 Fess 之前得先有一個可連線的 OpenSearch 實例。
Java 版本是硬性門檻。README 寫明 ZIP、RPM 與 DEB 套件需要 Java 21 或以上。舊環境若還停在 Java 17，這一步就得先處理。從原始碼建置同樣需要 Java 21 與 Maven，流程是先 `mvn antrun:run` 把 OpenSearch 外掛下載到 plugins 目錄，再於 IDE 中執行或除錯 org.codelibs.fess.FessBoot。打包則用 `mvn package` 產出到 target/releases，RPM 與 DEB 分別用 `mvn rpm:rpm` 與 `mvn jdeb:jdeb`。資料庫存取層若需要重新產生程式碼，README 給的序列是一次性的 `mvn dbflute:download`，之後 `mvn dbflute:freegen` 與 `mvn license:format`。
整合測試的門檻比單元測試高：需要一個執行中的 Fess 與 OpenSearch，且 SearchApiTests 還需要額外複製 fess-testdata 測試資料。README 提醒伺服器啟動可能需要 60 秒，可用 `curl -s "http://localhost:8080/api/v1/health"` 確認就緒，再以 `mvn test -P integrationTests` 搭配 `-Dtest.fess.url` 與 `-Dtest.search_engine.url` 兩個參數執行。
它不是輕量方案，也不是既有索引的查詢層
最明顯的限制是架構重量。Fess 是 Java 應用，背後必須有一個 OpenSearch 叢集，即使只是要搜尋幾百頁的內部文件也一樣。對比之下，靜態網站產生器的內建搜尋或單一檔案的索引方案，在這種規模下幾乎不需要維運。Fess 的價值要到資料來源分散、格式混雜、且需要權限區隔時才會顯現。
第二個限制是它對既有索引的態度。Fess 管理的是自己的索引結構與爬取流程，如果你的文件已經在既有的 OpenSearch 或 Elasticsearch 叢集裡，而且索引映射是你精心設計的，Fess 不會直接沿用。專案確實提供了 fess-ds-elasticsearch 這個資料存放區連接器，但那是把 Elasticsearch 當成爬取來源讀取，不是把 Fess 當成既有索引的前端。這兩件事常被混為一談，導入前必須分清楚。
第三個是格式解析的邊界。README 列出支援 Microsoft Office、PDF 與壓縮檔，但沒有說明掃描式 PDF 或圖片內文字如何處理，也沒有提到 OCR。若你的文件庫裡有大量掃描件，這部分需要另外查證官方文件，不能預設可用。
最後是升級成本。從釋出紀錄看，15.6.1、15.7.0 到 15.8.0 之間大約每隔一到兩個月一個版本，節奏相當緊湊。自架者要面對的是 Fess 本身與 OpenSearch 兩層的版本相容問題，README 只說「支援版本請見安裝指南」，並未在此列出對照表。這意味著升級前必須回頭查文件，不能只看 Fess 的版本號。
與直接用 OpenSearch 的差別在哪裡
最直接的替代方案就是自己用 OpenSearch 加上一支爬蟲。差異不在檢索能力，兩者底層是同一套引擎；差別在誰負責那條從來源到索引的管線。自己做的話，你得處理文件格式解析、增量抓取的排程、失敗重試、索引映射的維護，以及權限過濾要掛在查詢的哪一層。這些在 Fess 裡是設定頁上的欄位與排程項目。
反過來說，自建管線換到的是完全的控制權。你可以決定每個欄位怎麼分析、用什麼分詞器、查詢時怎麼加權，也可以只索引真正需要的那一小部分。Fess 把這些收進管理介面，好處是一致性，代價是當你需要一個它沒預期的查詢行為時，得走外掛或腳本路線，而不是改幾行設定。README 列出的 Groovy 與 OGNL 腳本外掛就是這個出口。
另一個方向是託管的搜尋服務。差別在資料邊界：Fess 是自架，文件不離開你的網路，這對內部規章不允許內容外送的組織是決定性的；託管服務則把維運、擴充與版本升級的責任轉移出去。README 沒有提供任何效能或規模數字，因此無法從這份材料判斷 Fess 在什麼資料量下會遇到瓶頸，這點只能靠自己的環境驗證。
授權與長期維護的實際帳
Fess 以 Apache-2.0 釋出，這個授權允許商業使用、修改與再散布，也包含專利授權條款。對於要把它包進內部系統或對外服務的團隊，這是相對寬鬆的選擇，不像 AGPL 那樣會對網路服務的提供方式產生額外義務。README 的建置流程裡出現 `mvn license:format`，說明專案對授權標頭的維護有自動化處理。這裡不構成法律意見，若你要把 Fess 與其他授權的元件一起散布，仍應由法務確認相容性。
維護成本主要落在兩個地方。第一是雙層版本管理：Fess 與 OpenSearch 的相容組合需要跟著官方安裝指南走，不能各自獨立升級。第二是外掛生態，README 列出的資料存放區連接器多達十餘個，每個都是獨立 repository，代表它們的更新節奏與 Fess 主體未必同步。當你把 Confluence、SharePoint 或 Salesforce 這類連接器接上正式環境，就等於同時依賴多個專案的維護狀況。
從釋出紀錄看，15.8.0 於 2026 年 8 月釋出，倉庫在 2026 年 9 月仍有推送，專案並未封存。但這份材料沒有提供安全性公告、支援週期或長期支援版本的資訊，因此無法判斷舊版會被維護多久。若你的環境有合規要求，這一點必須直接向專案確認。
編輯結論
如果你需要的是讓非工程背景的同事自行新增爬取目標、設定排程、用 LDAP 或 SAML 登入並依角色過濾結果，Fess 的瀏覽器管理介面省下的整合工時通常超過它帶來的維運負擔，值得採用。若你只需要對既有索引做低延遲的客製查詢，或已經有一套成熟的 OpenSearch 索引設計與用戶端程式，Fess 反而多了一層要維護的抽象。導入前請先確認三件事：目標環境的 Java 是否為 21 以上、OpenSearch 由 Fess 附帶的 Docker 映像提供還是自行架設、以及你需要的資料來源是否在 fess-ds-* 外掛清單內。這三項任一不成立，就得先解決再談部署。
社群筆記