🌐 Languages: 🇺🇸 English | 🇧🇷 Português (Brasil) | 🇪🇸 Español | 🇫🇷 Français | 🇮🇹 Italiano | 🇷🇺 Русский | 🇨🇳 中文 (简体) | 🇩🇪 Deutsch | 🇮🇳 हिन्दी | 🇹🇭 ไทย | 🇺🇦 Українська | 🇸🇦 العربية | 🇯🇵 日本語 | 🇻🇳 Tiếng Việt | 🇧🇬 Български | 🇩🇰 Dansk | 🇫🇮 Suomi | 🇮🇱 עברית | 🇭🇺 Magyar | 🇮🇩 Bahasa Indonesia | 🇰🇷 한국어 | 🇲🇾 Bahasa Melayu | 🇳🇱 Nederlands | 🇳🇴 Norsk | 🇵🇹 Português (Portugal) | 🇷🇴 Română | 🇵🇱 Polski | 🇸🇰 Slovenčina | 🇸🇪 Svenska | 🇵🇭 Filipino
Almindelige problemer og løsninger til OmniRoute.
| Problem | Løsning |
|---|---|
| Første login virker ikke | Tjek INITIAL_PASSWORD i .env (standard: 123456) |
| Dashboard åbner ved forkert port | Sæt PORT=20128 og NEXT_PUBLIC_BASE_URL=http://localhost:20128 |
Ingen anmodningslogfiler under logs/ |
Sæt ENABLE_REQUEST_LOGS=true |
| EACCES: tilladelse nægtet | Indstil DATA_DIR=/path/to/writable/dir til at tilsidesætte ~/.omniroute |
| Routingstrategi gemmer ikke | Opdatering til v1.4.11+ (Zod-skemafix for indstillinger persistens) |
Årsag: Udbyderkvoten er opbrugt.
Ret:
- Tjek dashboard kvotesporing
- Brug en kombination med reserveniveauer
- Skift til billigere/gratis niveau
Årsag: Abonnementskvoten er opbrugt.
Ret:
- Tilføj reserve:
cc/claude-opus-4-6 → glm/glm-4.7 → if/kimi-k2-thinking - Brug GLM/MiniMax som billig backup
OmniRoute opdaterer automatisk tokens. Hvis problemerne fortsætter:
- Dashboard → Udbyder → Genopret forbindelse
- Slet og tilføj udbyderforbindelsen igen
- Bekræft
BASE_URLpoint til din løbeforekomst (f.eks.http://localhost:20128) - Bekræft
CLOUD_URLpunkter til dit cloud-endepunkt (f.eks.https://omniroute.dev) - Hold
NEXT_PUBLIC_*værdier på linje med værdier på serversiden
Symptom: Unexpected token 'd'... på cloud-endepunkt til ikke-streamingopkald.
Årsag: Upstream returnerer SSE-nyttelast, mens klienten forventer JSON.
Løsning: Brug stream=true til direkte skyopkald. Lokal kørselstid inkluderer SSE→JSON fallback.
- Opret en ny nøgle fra det lokale dashboard (
/api/keys) - Kør skysynkronisering: Aktiver sky → Synkroniser nu
- Gamle/ikke-synkroniserede nøgler kan stadig returnere
401på skyen
- Tjek runtime-felter:
curl http://localhost:20128/api/cli-tools/runtime/codex | jq - For bærbar tilstand: brug billedmål
runner-cli(bundtede CLI'er) - For værtsmonteringstilstand: Indstil
CLI_EXTRA_PATHSog monter værtsbin-mappen som skrivebeskyttet - Hvis
installed=trueogrunnable=false: binær blev fundet, men helbredstjekket mislykkedes
curl -s http://localhost:20128/api/cli-tools/codex-settings | jq '{installed,runnable,commandPath,runtimeMode,reason}'
curl -s http://localhost:20128/api/cli-tools/claude-settings | jq '{installed,runnable,commandPath,runtimeMode,reason}'
curl -s http://localhost:20128/api/cli-tools/openclaw-settings | jq '{installed,runnable,commandPath,runtimeMode,reason}'- Tjek brugsstatistik i Dashboard → Brug
- Skift primær model til GLM/MiniMax
- Brug gratis niveau (Gemini CLI, iFlow) til ikke-kritiske opgaver
- Indstil omkostningsbudgetter pr. API-nøgle: Dashboard → API-nøgler → Budget
Indstil ENABLE_REQUEST_LOGS=true i din .env fil. Logfiler vises under biblioteket logs/.
# Health dashboard
http://localhost:20128/dashboard/health
# API health check
curl http://localhost:20128/api/monitoring/health- Hovedtilstand:
${DATA_DIR}/db.json(udbydere, kombinationer, aliaser, nøgler, indstillinger) - Anvendelse:
${DATA_DIR}/usage.json,${DATA_DIR}/log.txt,${DATA_DIR}/call_logs/ - Anmodningslogfiler:
<repo>/logs/...(nårENABLE_REQUEST_LOGS=true)
Når en udbyders afbryder er ÅBEN, blokeres anmodninger, indtil nedkølingen udløber.
Ret:
- Gå til Dashboard → Indstillinger → Resiliens
- Tjek afbryderkortet for den berørte udbyder
- Klik på Nulstil alle for at rydde alle afbrydere, eller vent på, at nedkølingen udløber
- Bekræft, at udbyderen faktisk er tilgængelig, før du nulstiller
Hvis en udbyder gentagne gange går i ÅBEN tilstand:
- Tjek Dashboard → Health → Provider Health for fejlmønsteret
- Gå til Indstillinger → Resiliens → Udbyderprofiler og øg fejltærsklen
- Tjek, om udbyderen har ændret API-grænser eller kræver gengodkendelse
- Gennemgå latency-telemetri — høj latenstid kan forårsage timeout-baserede fejl
- Sørg for, at du bruger det korrekte præfiks:
deepgram/nova-3ellerassemblyai/best - Bekræft, at udbyderen er tilsluttet i Dashboard → Udbydere
- Tjek understøttede lydformater:
mp3,wav,m4a,flac,ogg,webm - Bekræft filstørrelsen er inden for udbyderens grænser (typisk < 25 MB)
- Tjek gyldigheden af udbyderens API-nøgle på udbyderkortet
Brug Dashboard → Oversætter til at fejlfinde problemer med formatoversættelse:
| Tilstand | Hvornår skal man bruge |
|---|---|
| Legeplads | Sammenlign input/output-formater side om side — indsæt en mislykket anmodning for at se, hvordan den oversættes |
| Chattester | Send livebeskeder og inspicer den fulde anmodnings-/svarnyttelast inklusive overskrifter |
| Testbænk | Kør batchtest på tværs af formatkombinationer for at finde ud af, hvilke oversættelser der er brudte |
| Live Monitor | Se anmodningsflow i realtid for at fange periodiske oversættelsesproblemer |
- Tænke-tags vises ikke — Tjek, om måludbyderen understøtter tænkning og indstilling af tænkebudget
- Værktøjsopkald falder — Nogle formatoversættelser kan fjerne ikke-understøttede felter; verificere i Playground-tilstand
- Systemprompt mangler — Claude og Gemini håndterer systemprompts forskelligt; kontrollere oversættelsesoutput
- SDK returnerer rå streng i stedet for objekt — Rettet i v1.1.0: Response Sanizer fjerner nu ikke-standardfelter (
x_groq,usage_breakdownosv.), der forårsager OpenAI SDK Pydantic valideringsfejl - GLM/ERNIE afviser
systemrolle — Rettet i v1.1.0: Rollenormalisering flettes automatisk systemmeddelelser ind i brugermeddelelser for inkompatible modeller developerrolle ikke genkendt — Rettet i v1.1.0: automatisk konverteret tilsystemfor ikke-OpenAI-udbyderejson_schemavirker ikke med Gemini — Rettet i v1.1.0:response_formater nu konverteret til Gemini'sresponseMimeType+responseSchema
- Automatisk hastighedsgrænse gælder kun for API-nøgleudbydere (ikke OAuth/abonnement)
- Bekræft, at Indstillinger → Modstandsdygtighed → Udbyderprofiler har aktiveret automatisk satsgrænse
- Tjek, om udbyderen returnerer
429statuskoder ellerRetry-Afteroverskrifter
Udbyderprofiler understøtter disse indstillinger:
- Base delay — Indledende ventetid efter første fejl (standard: 1s)
- Maksimal forsinkelse — Maksimal ventetid (standard: 30s)
- Multiplikator — Hvor meget skal forsinkelsen øges pr. på hinanden følgende fejl (standard: 2x)
Når mange samtidige anmodninger rammer en hastighedsbegrænset udbyder, bruger OmniRoute mutex + automatisk hastighedsbegrænsning til at serialisere anmodninger og forhindre kaskadefejl. Dette er automatisk for API-nøgleudbydere.
- GitHub-problemer: github.com/diegosouzapw/OmniRoute/issues
- Arkitektur: Se link for interne detaljer
- API-reference: Se link for alle endepunkter
- Health Dashboard: Tjek Dashboard → Health for systemstatus i realtid
- Oversætter: Brug Dashboard → Oversætter til at fejlsøge formatproblemer