Client: Open WebUI (Browser / UI)
1)
HTTPS (TCP/443): "normale" REST/Fetch Requests (Über SSL)
Statische Assets (UI laden)
GET / (HTML)
GET /assets/... (JS/CSS/Fonts)
GET /favicon..., GET /manifest... etc.
REST API Calls (Open WebUI Backend)
Model-Liste: GET /api/models
Chat (OpenAI-kompatibel): POST /api/chat/completions
Je nach UI-Aktion zusätzlich viele GET/POST unter /api/... und /api/v1/... (Chats, Messages, Dateien, Benutzer/Settings, Tools, RAG, etc.)
2)
WebSocket (WSS über 443, ebenfalls "SSL"): Streaming/Realtime
(Je nach Proxy/Setup kann es auch Polling-Requests gegen denselben Pfad geben; das sieht man dann als GET /ws/socket.io/... transport=polling ....)
Open WebUI API
1)
Model Provider (HTTP/HTTPS)
Ollama (meist HTTP zu einem internen Host/Container-Port; je nach Setup)
OpenAI-kompatible Provider (z. B. OpenAI oder LiteLLM, lokale Gateways, etc.). Open WebUI ist "protocol-first" und spricht Chat-Completions-kompatibel.
2)
WebSocket-Scaling / Manager (Redis)
Bei Multi-Instance/Scaling kann Open WebUI Redis für WebSocket-Management nutzen: WEBSOCKET_REDIS_URL=redis://...
-> Das ist Server-> Redis Traffic (nicht Browser-> Redis).
3)
RAG / Vector DB / Dokumente / Web-Suche / TTS-STT
Je nach aktivierten Features kann Traffic gehen zu:
Vector DB/Stores (z. B. Chroma/andere) (HTTP)
Web-Suche (externe Search APIs)
Speech-to-Text / Text-to-Speech Provider (HTTP)
Tool-Server/Integrationen
(Die Menge ist stark feature-abhängig, da es dafür viele optionale "Outgoing"-Ziele gibt.)