MockServer 7.6.0：單一埠接管 HTTP、gRPC 與 TCP 的測試替身
MockServer is an HTTP(S) mock server and proxy for testing that lets you mock APIs, inspect and modify live traffic, and inject failures. It supports HTTP/1.1, HTTP/2, gRPC, WebSockets, TCP and more on a single port, with additional support for HTTP/3, message brokers, and AI/LLM APIs.
秒懂
- 它是什麼？
- MockServer 把 mock、代理與混沌注入收在同一個埠上，靠首封包自動辨識協定。本文整理它的運作機制、啟動指令、真正的限制，以及它與 WireMock 在設計取向上的差別。
- 適合誰用？
- 需要同時 mock HTTP、gRPC 與 raw TCP，或想把代理錄製、斷線注入放進同一套測試流程的團隊，可以從 docker run -d --rm -p 1080:1080 mockserver/mockserver 與 PUT /mockserver/expectation 開始評估。只需要在 JVM 測試內用 Java DSL 描述幾個 HTTP 端點、且不希望額外維運一個常駐服務的專案，WireMock 的 in-process 模式更省事。
- 可以商用嗎？
- 可以。Apache-2.0 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 Java（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它解決的是依賴不可控，而不是單一 API 的假資料
多數 mock 工具處理的是「這個端點還沒寫好」。MockServer 要處理的範圍更寬：你的服務依賴的系統可能尚未完成、可能只在特定環境存在、可能難以重現某種失敗，也可能是第三方服務。README 把功能分成三塊，mock、proxy、chaos engineering，這個切法本身就說明了目標讀者。
需要 mock 的人通常是後端或整合測試工程師，他們要讓 CI 在沒有外部依賴的情況下跑完。需要 proxy 的人是那些手上只有真實流量、沒有規格的人：把 MockServer 當 web proxy 或 CONNECT 通道，錄下請求與回應，再回頭整理成 expectations。需要混沌注入的人則是要驗證自己的重試、timeout、circuit breaker 在對方變慢或斷線時是否真的生效。這三種需求過去通常要三套工具，MockServer 把它們放在同一個控制平面上。
值得注意的是它對協定的態度。文件列出 HTTP/1.1、HTTPS、HTTP/2、gRPC 與 gRPC-Web、WebSockets、raw TCP，並說這些是從每個連線的前幾個位元組自動偵測，不需要逐協定設定。對同時有 REST 與 gRPC 依賴的服務來說，這意味著不必為了不同協定開不同埠、寫不同啟動設定。
首封包協定辨識與同一埠上的控制平面
MockServer 的架構核心是埠的複用。文件描述它會從連線開頭的前幾個位元組判斷這是 HTTP/1.1、HTTP/2、gRPC、WebSocket 還是 raw TCP，因此單一埠就能承接全部。HTTP/3 是例外，它走 QUIC，需要自己的 UDP 埠，而且文件明確標示為 experimental。
第二個關鍵設計是控制平面與被 mock 的服務共用同一個埠。README 的範例裡，設定 expectation 是對 http://localhost:1080/mockserver/expectation 發 PUT，而被 mock 的端點是 http://localhost:1080/hello。這種安排讓啟動參數少一個，但也代表你的 mock 路徑不能與 /mockserver 前綴衝突，這是使用時要自己避開的命名空間。
請求比對的維度在文件中有具體列出：method、path、query、headers、cookies 與 body，body 可比對 JSON、XML、JSONPath、XPath、regex 與 OpenAPI。回應端則支援 Velocity、Mustache、JavaScript 樣板，以及 class/closure callback 與 webhook。這意味著回應內容可以依請求內容動態產生，不必為每個組合各寫一條 expectation。
狀態存放方式決定了部署形態。文件提到多實例部署可啟用選用的叢集狀態，反過來說，不啟用時每個實例各自持有自己的 expectations 與錄製紀錄。如果你打算在 Kubernetes 上跑多個副本，這個開關不是可選項。
從 docker run 到 PUT expectation 的三步
README 給的最短路徑是 Docker：
docker run -d --rm -p 1080:1080 mockserver/mockserver
接著用控制平面建立一條 expectation：
curl -X PUT http://localhost:1080/mockserver/expectation -H 'Content-Type: application/json' -d '{"httpRequest":{"method":"GET","path":"/hello"},"httpResponse":{"statusCode":200,"body":"Hello World"}}'
然後直接呼叫被 mock 的路徑：curl http://localhost:1080/hello。這個流程不需要寫任何 Java 程式碼，也不需要掛載設定檔，是它相對於同類工具最明顯的入門優勢。
macOS 與 Linux 上另有 Homebrew 路徑：brew install mockserver，再執行 mockserver run --port 1080。文件也列出 JAR、WAR、Helm/Kubernetes、Testcontainers，以及 examples/docker-compose 底下的一鍵配方，包含 mock-from-openapi、record/replay proxy、contract-validating proxy 與 chaos proxy。以 mock-from-openapi 為例，進入該目錄後 docker compose up，再 curl http://localhost:1080/pets 即可。
觀察介面在 /mockserver/dashboard，可以看到即時的請求、expectations 與日誌。AI 整合方面，內建的 MCP server 掛在 /mockserver/mcp，供 AI 編碼助理使用。這兩個路徑都與被 mock 的路徑共用同一個埠。
代理中斷點是它與一般 mock 工具的分界
README 對 proxy 的描述不只是轉發與錄製，還包括 proxy breakpoints：把每個交換暫停下來，逐步檢視、編輯或中止，文件把它比喻成網路流量的除錯器。這是一個少見的能力，因為多數錄製工具只提供事後檢視。
代理形態涵蓋 port forwarding、web proxy、HTTPS tunneling（CONNECT）與 SOCKS，文件聲稱即使是 TLS 加密流量也有完整可視性。這裡要提醒的是，這類能力在真實環境使用時會牽涉憑證與中間人設定的問題，而文件沒有在 README 中展開這部分，實際部署前應該查閱 self-hosting 與 Docker 章節的細節。
驗證功能與代理是互補的。MockServer 可以斷言收到哪些請求、順序為何、各出現幾次。把錄製下來的真實流量轉成斷言，是這條路線的典型用法：先用代理觀察，再用驗證把行為固定下來。
混沌注入則是在 expectation 上疊加延遲、連線中斷與錯誤。它與 mock 共用同一套比對語言，所以「這個路徑正常回應」與「這個路徑慢 5 秒後斷線」可以用同一種描述方式表達，切換成本低。
什麼時候不該用它
第一個限制是執行形態。MockServer 是一個獨立的 Java 服務，即使有 Testcontainers 與 JUnit 支援，它的預設心智模型仍是「先有一個常駐的埠」。如果你的測試只需要在 JVM 內描述幾個 HTTP 端點，而且不希望測試啟動流程多一個容器或外部程序，這個模型就是多餘的。
第二個限制是 JVM 生態的偏向。客戶端有 Java、JavaScript/Node、Python 與 Ruby，聽起來覆蓋面夠，但主體、文件與架構文件都在 Java 這一側。非 JVM 團隊要用得好，多半得直接操作 REST 控制平面，而不是依賴語言客戶端的抽象。這不是缺點，只是要先想清楚你要走哪條路。
第三個限制寫在文件裡：HTTP/3 標示為 experimental，且使用獨立的 UDP 埠。如果你的測試環境網路政策只允許 TCP，這一項等於不存在。
第四個是狀態。多實例部署需要啟用選用的叢集狀態，否則 expectations 不會共享。這在單機測試時完全無感，一旦搬上 Kubernetes 就會變成難以診斷的問題，因為每個副本都可能給出不同答案。
最後是範圍本身。MockServer 支援 Kafka 與 MQTT 的訊息代理測試，也支援 mock OpenAI、Anthropic、Gemini、Bedrock、Azure OpenAI 與 Ollama 的 chat-completion API（含串流）。這些能力確實存在，但它們的成熟度與核心 HTTP mock 不會是同一條曲線，把它們當成採用理由之前應該先單獨驗證。
與 WireMock 的差別在部署模型，不在功能清單
拿 WireMock 對比最有意義的地方是執行模型。WireMock 同樣是 Java 專案，同樣能獨立執行，但它的主要使用方式是嵌入測試 JVM，用 Java DSL 在測試方法內宣告 stub，測試結束即消失。MockServer 的預設路徑是啟動服務，再從外部用 REST 控制平面或用戶端設定 expectations。前者適合單元與元件測試，後者適合跨程序、跨語言的整合測試。
協定覆蓋是第二個差異點。WireMock 的核心是 HTTP，gRPC 需要額外擴充。MockServer 把 HTTP/1.1、HTTP/2、gRPC、WebSockets 與 raw TCP 放進同一個埠自動辨識，這對同時有這幾種連線的系統是實質差別。
代理與混沌是第三個差異點。WireMock 有錄製與代理模式，但 MockServer 的 proxy breakpoints 與內建的延遲、斷線注入，把除錯與韌性測試放進了同一條工作流。
反過來說，如果你的情境是純 HTTP、純 JVM、每個測試類別各自宣告 stub，WireMock 的 in-process 模型會少掉一個需要維運的服務，這是 MockServer 換不來的。選擇的關鍵不是功能多寡，而是你的測試是「在測試程序內」還是「在測試程序外」。
授權、維護成本與升級要看的東西
授權是 Apache-2.0，README 與 repository 的 LICENSE.md 都指向同一個識別碼。這是一個寬鬆授權，允許商用與修改，但這裡不提供法律意見；如果你的產品需要處理授權合規，應該由法務確認 Apache-2.0 的專利與商標條款在你的情境下如何適用。
維護成本的來源不是程式碼，而是那個常駐服務。Docker 映像、Helm chart、JAR、WAR 與 Homebrew 這幾條路徑各自有升級節奏，版本落後會讓控制平面的行為與文件對不上。從 release 紀錄看，7.4.0、7.5.0、7.6.0 分別落在 2026 年 7 月 4 日、7 月 29 日與 8 月 17 日，一個多月內三個 minor 版本，代表這個專案的變動頻率高於一般基礎設施元件。把映像標籤固定在具體版本，而不是 latest，會比事後追查行為差異便宜。
升級時要看的具體項目：changelog.md 在 repository 根目錄，README 也指向它；控制平面的路徑前綴 /mockserver 是否在新版本有調整；如果你用了 MCP 整合，/mockserver/mcp 的行為是否跟著變；如果你用了 OpenAPI 產生 expectations，規格解析的結果是否一致。這四項都能在升級前用既有的 expectations 跑一輪驗證來確認，不需要讀完整份 changelog。
最後，這個專案沒有封存，最後推送時間是 2026 年 9 月 9 日，預設分支是 master。這代表它仍在維護中，但不代表每個子功能都在同一個成熟度上，HTTP/3 的 experimental 標記就是明證。
編輯結論
需要同時 mock HTTP、gRPC 與 raw TCP，或想把代理錄製、斷線注入放進同一套測試流程的團隊，可以從 docker run -d --rm -p 1080:1080 mockserver/mockserver 與 PUT /mockserver/expectation 開始評估。只需要在 JVM 測試內用 Java DSL 描述幾個 HTTP 端點、且不希望額外維運一個常駐服務的專案，WireMock 的 in-process 模式更省事。採用前先確認三件事：HTTP/3 在文件中被標為 experimental，且使用獨立的 UDP 埠，不是 1080；多實例部署需要啟用選用的叢集狀態，否則各節點各自持有 expectations；依賴 OpenAPI 產生 expectations 的流程要先確認規格檔版本能被正確解析，再決定是否納入 CI。
社群筆記