MockServer: Mock, Proxy und Chaos-Engineering auf einem Port

Drei Rollen in einem Prozess

MockServer tritt in drei Rollen auf, die sich denselben Port teilen: als Mock-Server, der konfigurierte Antworten auf passende Anfragen zurückgibt, als Proxy, der echten Verkehr weiterleitet, aufzeichnet und unterwegs verändern kann, und als Werkzeug für Chaos-Engineering, das Abhängigkeiten gezielt langsam, fehlerhaft oder gar nicht antworten lässt. Die Zielgruppe sind Teams, die gegen Systeme testen müssen, die nicht verfügbar, unvollständig oder schwer reproduzierbar sind. Der README nennt als Beispiel ausdrücklich Systeme, die "unavailable, incomplete, or hard to reproduce" sind. Wer eine API nur stubben will, bekommt hier mehr mitgeliefert, als er braucht, und trägt auch die Kosten dafür.

Protokollererkennung an den ersten Bytes

Der technisch interessanteste Teil ist die Anschlussbehandlung. Laut README werden HTTP/1.1 und HTTPS, HTTP/2, gRPC und gRPC-Web, WebSockets sowie rohes TCP anhand der ersten Bytes einer Verbindung automatisch erkannt. Ein einzelner MockServer-Port bedient damit alle diese Protokolle, ohne dass pro Protokoll konfiguriert werden muss. Das ist der Grund, warum sich MockServer in heterogenen Stacks anders verhält als ein reiner HTTP-Stubber: Ein gRPC-Aufruf und eine WebSocket-Verbindung landen auf derselben Adresse wie ein gewöhnlicher REST-Aufruf, und der Server entscheidet erst beim Lesen des Verbindungsanfangs, wohin der Verkehr gehört. Diese Automatik ist bequem, sie macht aber auch die Fehlersuche ungewohnt: Wenn ein Client sich gegen den falschen Dienst verbindet, sieht man das nicht an einem falschen Port, sondern an einer falschen Interpretation der ersten Bytes. HTTP/3 über QUIC läuft laut README experimentell auf einem eigenen UDP-Port und fällt damit aus der Ein-Port-Logik heraus.

Steuerungsebene über REST auf demselben Port

MockServer bringt eine REST-Steuerungsebene mit, die auf demselben Port wie der gemockte Verkehr liegt. Der README zeigt den vollständigen Ablauf: Start per docker run -d --rm -p 1080:1080 mockserver/mockserver, dann ein PUT auf http://localhost:1080/mockserver/expectation mit einem JSON-Körper, der httpRequest und httpResponse beschreibt, danach der eigentliche Aufruf gegen den gemockten Pfad. Wer keine Container einsetzen will, installiert das Paket per brew install mockserver und startet es mit mockserver run --port 1080. Das Dashboard erreicht man unter /mockserver/dashboard, der eingebaute MCP-Server für KI-Werkzeuge liegt unter /mockserver/mcp. Bemerkenswert ist, dass die Konfiguration selbst über HTTP läuft. Das erleichtert Skripte und den Aufruf aus Tests, es bedeutet aber auch, dass jeder, der den Port erreicht, Expectations anlegen oder löschen kann. Für eine Testinstanz ist das meist akzeptabel, für eine länger laufende Umgebung mit erreichbarem Netzwerk ist es eine Entscheidung, die man bewusst treffen sollte.

Expectations aus einer OpenAPI-Spezifikation

Statt jede Antwort einzeln zu schreiben, kann MockServer Expectations direkt aus einer OpenAPI- oder Swagger-Spezifikation erzeugen. Der README verweist dafür auf die docker-compose-Rezepte unter examples/docker-compose, darunter mock-from-openapi. Der Ablauf ist dort ein einziges docker compose up, gefolgt von einem curl auf http://localhost:1080/pets. Das ist der pragmatischste Einstieg, weil er die Frage umgeht, wie viele Expectations man von Hand pflegen will. Die Grenze liegt in der Spezifikation selbst: Was dort nicht beschrieben ist, kann auch nicht generiert werden. Ein Spec, das nur Pfade und Statuscodes auflistet, liefert entsprechend dünne Antworten. Ob die generierten Expectations zu den eigenen Tests passen, lässt sich nur durch Ausprobieren feststellen, und genau dafür ist das Rezept gedacht.

Proxy-Betrieb und der Bruchpunkt im Datenverkehr

Im Proxy-Modus leitet MockServer echten Verkehr weiter und zeichnet ihn auf. Der README nennt Portweiterleitung, einen Web-Proxy, HTTPS-Tunneling über CONNECT sowie SOCKS, und er beansprucht Sichtbarkeit auch auf TLS-verschlüsselten Verkehr. Zusätzlich gibt es interaktive Proxy-Bruchpunkte, an denen sich jeder Austausch anhalten, bearbeiten oder abbrechen lässt, laut README "like a debugger for network traffic". Das ist ein anderer Arbeitsablauf als das nachträgliche Auswerten von Logs: Man greift in eine laufende Verbindung ein. Für die Fehlersuche an einem fremden Dienst ist das nützlich. Für automatisierte Testläufe ist es die falsche Betriebsart, weil ein angehaltener Austausch auf eine menschliche Entscheidung wartet. Teams sollten den Proxy-Modus deshalb nicht als Standard für die CI einstellen, sondern als Werkzeug für die manuelle Analyse behandeln. Der zweite Proxy-nahe Anwendungsfall, das Aufzeichnen und späteres Wiedergeben, ist im README als record/replay-Rezept in examples/docker-compose erwähnt.

Chaos-Injektion und KI-Endpunkte

Für Belastungstests lassen sich Latenz, abgebrochene oder langsame Verbindungen und Fehler injizieren. Der Sinn ist nicht, den eigenen Code zu testen, sondern das Verhalten gegenüber einer Abhängigkeit, die sich falsch verhält. Das ist ein eigenes Testfeld und nicht dasselbe wie ein Mock mit festen Antworten. Wer nur deterministische Antworten braucht, wird diesen Teil nie konfigurieren. Auf der anderen Seite listet der README das Mocking von Chat-Completion-APIs für OpenAI, Anthropic, Gemini, Bedrock, Azure OpenAI und Ollama, inklusive Streaming. Das ist ein junger Anwendungsfall, der vor allem Kosten und Rate-Limits in Testläufen vermeiden soll. Beide Bereiche erweitern die Angriffsfläche der Konfiguration deutlich. Man sollte vor dem Einsatz prüfen, welche dieser Endpunkte im eigenen Testlauf überhaupt angesprochen werden, statt die volle Breite zu aktivieren.

Grenzen, Betriebsform und Lizenz

MockServer ist ein Java-Projekt und wird als Docker-Image, als JAR, als WAR, per Helm für Kubernetes und über Homebrew verteilt. Für Umgebungen ohne JVM nennt der README ein eigenes Binary-Bundle. Daraus folgt die erste Einschränkung: Es läuft immer ein JVM-Prozess mit, auch wenn nur ein einzelner Endpunkt gestubbt werden soll. Die zweite betrifft den Zustand. Der README erwähnt optionalen geclusterten Zustand für Multi-Instanz-Deployments. Ob Expectations zwischen Instanzen geteilt werden oder pro Instanz gelten, hängt von dieser Option ab, und wer mehrere Instanzen hinter einem Load Balancer betreibt, muss das vor dem Rollout klären. Eine dritte Einschränkung ist die Protokollbreite selbst: HTTP/3 ist laut README experimentell, und die Unterstützung für Nachrichtenbroker wie Kafka und MQTT richtet sich an externe Broker, nicht an einen eingebauten. Wer einen Broker ohne externe Abhängigkeit mocken will, wird hier nicht fündig. Zur Lizenz: Das Projekt steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und geänderte Dateien gekennzeichnet werden. Wer MockServer in ein eigenes Produkt einbettet oder weiterverteilt, sollte die Bedingungen mit der eigenen Rechtsabteilung prüfen; dieser Text ist keine Rechtsberatung. Für die Wartung gilt: Die letzten Releases liegen dicht beieinander (7.4.0 im Juli, 7.5.0 und 7.6.0 im Juli und August 2026), was auf aktive Pflege hindeutet. Upgrade-Kosten entstehen vor allem, wenn man die REST-Steuerungsebene direkt anspricht und sich das JSON-Schema von Expectations zwischen Versionen ändert. Wer stattdessen einen der Clients für Java, JavaScript/Node, Python oder Ruby nutzt, verlagert dieses Risiko in die Client-Bibliothek, muss dann aber deren Versionsstand mit dem Server abgleichen.

Wann ein schlankerer Ersatz die bessere Wahl ist

Die naheliegende Alternative ist WireMock. Beide stubben HTTP-Endpunkte über eine JSON-Konfiguration, beide lassen sich als JAR oder Container betreiben. Der Unterschied liegt im Zuschnitt: WireMock ist auf HTTP und dessen Varianten konzentriert, während MockServer zusätzlich gRPC, WebSockets, rohes TCP und Nachrichtenbroker abdeckt und die Protokollererkennung automatisch vornimmt. Wer ausschließlich REST-Endpunkte stubbt, zahlt bei MockServer für Fähigkeiten, die er nicht nutzt, und bekommt dafür eine größere Konfigurationsfläche. Eine zweite Alternative ist ein gewöhnlicher HTTP-Reverse-Proxy mit statischen Antwortdateien. Der kann weder Expectations dynamisch anlegen noch Anfragen verifizieren, ist dafür aber ohne JVM und ohne Steuerungsebene zu betreiben. Die Entscheidung hängt damit an einer einzigen Frage: Braucht der Testlauf mehr als HTTP, oder reicht ein Stubber für REST? Wer diese Frage mit Nein beantwortet, sollte den kleineren Werkzeugen den Vorzug geben.

Redaktionelles Fazit

MockServer passt zu Teams, die HTTP, gRPC, WebSockets und TCP in einer Testumgebung abdecken und den Proxy-Modus zum Aufzeichnen oder für Fehlerinjektion nutzen wollen, ohne pro Protokoll einen eigenen Dienst zu betreiben. Wer nur eine Handvoll REST-Endpunkte stubben will, fährt mit einem WireMock-JAR oder einem HTTP-Reverse-Proxy mit Datei-Backend schlanker, weil dort keine JVM mit Dashboard, Clustering-Option und MCP-Endpunkt mitläuft. Vor dem Rollout ist zu klären, ob die Chaos-Injektion im eigenen Stack tatsächlich benötigt wird, ob die experimentelle HTTP/3-Unterstützung auf einem separaten UDP-Port im Zielnetz erreichbar ist und ob die Apache-2.0-Lizenz mit der eigenen Distributionsform vereinbar ist. Der erste konkrete Schritt ist ein docker compose up im Verzeichnis examples/docker-compose/mock-from-openapi, gefolgt von einem curl auf http://localhost:1080/pets, um zu sehen, ob die generierten Expectations zum eigenen Spec passen.

Offizielle Quellen

1. License: Apache-2.0
2. mock-server/mockserver-monorepo on GitHub
3. Project website
4. README
5. Releases