mirror of https://github.com/diegosouzapw/OmniRoute.git synced 2026-10-19 05:20:05 +00:00

Diego Rodrigues de Sa e Souza 453918ab64

docs(i18n): refresh 19 drifted docs across 66 locales and fix the db module count (#15123 )

* docs: correct the src/lib/db module count to 136 in README and REPOSITORY_MAP

* docs(i18n): refresh 19 drifted docs across 66 locales

Re-translates every locale of the 19 docs the base edited without updating
their translations (README, USER_GUIDE, API_REFERENCE, ENVIRONMENT,
FEATURE_FLAGS, PROVIDER_REFERENCE, AUTO-COMBO, REPOSITORY_MAP, CORS and
others). 1254 mirrors; every one passed the output guard and a
structure/leak check against its source.

2026-09-29 15:12:29 -03:00

60 KiB

Raw Blame History

Troubleshooting (Latviešu)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇧🇦 bs · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇱 he · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW

Lietotājiem: Vai meklējat ātrus risinājumus? Skatiet tālāk esošo ātro uzziņu.

Biežāk sastopamās OmniRoute problēmas un to risinājumi.

Ātrā uzziņa

Pirmoreiz izmantojat OmniRoute? Sāciet šeit — šie risinājumi novērš 90% problēmu:

Es redzu šo	Ko tas nozīmē	Ko darīt
"Nevar izveidot savienojumu"	OmniRoute nedarbojas	Palaidiet `omniroute` vai `docker restart omniroute`
"Nederīga API atslēga"	Jūsu atslēga ir nepareiza vai tai beidzies termiņš	Vēlreiz nokopējiet atslēgu no pakalpojumu sniedzēja vietnes
"Pārsniegts ātruma ierobežojums"	Jūs sūtāt pārāk daudz pieprasījumu	Uzgaidiet 1 minūti vai izmantojiet `model: "auto"` automātiskai pārslēgšanai
"Pārsniegta kvota"	Esat izlietojis savu bezmaksas/maksas kvotu	Pievienojiet vairāk pakalpojumu sniedzēju vai izmantojiet bezmaksas pakalpojumu sniedzējus (Kiro, Pollinations)
"Lēnas atbildes"	Pakalpojumu sniedzējs ir noslogots vai atrodas tālu	Izmantojiet `model: "auto/fast"` vai pievienojiet ātrāku pakalpojumu sniedzēju (Groq, Cerebras)
"Izmantots nepareizs pakalpojumu sniedzējs"	`auto` izvēlējās citu pakalpojumu sniedzēju	Tas ir normāli! `auto` izvēlas labāko. Norādiet konkrētu pakalpojumu sniedzēju ar `model: "openai/gpt-4o"`
"502 Nederīga vārteja"	Pakalpojumu sniedzējs nedarbojas	Uzgaidiet un mēģiniet vēlreiz vai izmantojiet `model: "auto"`, lai pārslēgtos uz citu pakalpojumu sniedzēju
"401 Nav autorizācijas"	Jūsu akreditācijas dati ir nepareizi	Pārbaudiet savu API atslēgu vai atkārtoti autentificējieties, izmantojot OAuth
"omniroute netiek atpazīts"	Windows PATH nav iekļauti globālie node moduļi	Pievienojiet savu npm globālo prefiksu Windows PATH. Atrodiet to ar `npm config get prefix`.
"429 Pārāk daudz pieprasījumu"	Piemērots ātruma ierobežojums	Uzgaidiet 1 minūti vai pievienojiet vairāk pakalpojumu sniedzēju

Joprojām neizdodas? Skatiet tālāk detalizēto problēmu novēršanu vai jautājiet Discord.

Detalizēta problēmu novēršana

Bezmaksas pakalpojumu sniedzēju pieprasījumu biežuma ierobežošana (429 / 400 / 401)

Simptoms: Izmantojot model: "auto" ar bezmaksas/autentifikāciju neprasošiem pakalpojumu sniedzējiem (opencode, auggie u.c.), atbilžu vietā periodiski tiek saņemts HTTP 429, 400 vai 401. Atkārtoti nosūtot to pašu uzvedni pēc neilga brīža, pieprasījumi izdodas, taču automatizācija (cron uzdevumi, aģenti, skripti) pārtrauc darbību jau pēc pirmās kļūmes.

Pamatcēlonis: Vienlaikus pārklājas trīs neatkarīgi kļūmju režīmi:

Pakalpojumu sniedzēja pieprasījumu biežuma ierobežojums (429): Bezmaksas līmeņiem var būt noteikta kvota katram laika periodam. Paralēlu izsaukumu vilnis to izsmeļ, tāpēc nākamais pieprasījums tiek noraidīts, līdz attiecīgais periods tiek atiestatīts.
Bojāts modelis tranzīta režīmā (400/401): auto/* kopās var būt iekļauti opencode tranzīta modeļi, kas ir reģistrēti katalogā, bet kuriem nav aktīvu akreditācijas datu (piem., oc/north-mini-code-free → 401). Automātiskais maršrutētājs izmēģina vienu no tiem, tas cieš neveiksmi, un kļūda tiek pārsūtīta, pirms tiek aktivizēta atkāpšanās.
Vienlaicīguma izraisīta pastiprināšanās (429 slodzes laikā): Kad vairākas aģenta/cron sesijas vienlaikus izmanto auto, kopējais pieprasījumu biežums pārsniedz bezmaksas pakalpojumu sniedzēju pieļaujamo līmeni, tāpēc likumīgi izsaukumi tiek atzīmēti kā ļaunprātīgi.

Pārbaudīts risinājums (kopienas ziņojums, 2026-08-10): pielāgojiet trīs vides mainīgos, lai rotācija, vienlaicīguma pārvaldība un atkāpšanās absorbētu bezmaksas līmeņa svārstības, nevis to dēļ pārtrauktu darbību:

export OMNIROUTE_ROTATE_ON_400=true           # 400/401 gadījumā pāriet uz citu modeli/pakalpojumu sniedzēju (izlaiž bojātus tranzīta modeļus)
export OMNIROUTE_CHAT_MAX_HEAVY_IN_FLIGHT=4   # precīzi noteikts smagsvara pieprasījumu uzņemšanas maksimums (pēc noklusējuma nav iestatīts: nav pieprasījumu skaita ierobežojuma; skatiet piezīmi tālāk)
export OMNIROUTE_CHAT_ADMISSION_QUEUE_MS=20000 # palielina ierobežoto gaidīšanas laiku virs RATE_LIMIT_MAX_WAIT_MS noklusējuma lēniem augšupējiem pakalpojumiem

Iestatiet tos OmniRoute procesa vidē (dēmonam, piemēram, izmantojot LaunchAgent plist vai systemctl edit) un pēc tam restartējiet OmniRoute. Rotācijas karodziņš ir vienīgais visietekmīgākais iestatījums: tas pārvērš pilnīgu kļūmi pārredzamā atkārtotā mēģinājumā, izmantojot veselīgu pakalpojumu sniedzēju no kopas.

Piezīme: OMNIROUTE_CHAT_MAX_HEAVY_IN_FLIGHT ierobežo vienlaikus izpildāmo smagsvara — gara konteksta — pieprasījumu skaitu; šis ierobežojums ir uzņemšanas vārteja, nevis pakalpojumu sniedzēja pieprasījumu biežuma ierobežotājs. #503-fanout atjauninājums: šis mainīgais pēc noklusējuma vairs netiek iestatīts (tagad tas tiek lietots tikai tad, ja ir skaidri konfigurēts, kā parādīts iepriekš) — tā vietā smagsvara pieprasījumu uzņemšanu regulē automātiski atvasināts baitu budžets (OMNIROUTE_CHAT_MAX_INFLIGHT_BYTES), kas pats mērogojas atbilstoši resursdatora faktiskajam atmiņas ierobežojumam, tādēļ jaunā izvietojumā vajadzētu būt ievērojami mazāk 503 chat_admission_busy noraidījumu, pat vispār neiestatot šo mainīgo; tā nepārprotama iestatīšana šeit joprojām darbojas tieši tā, kā dokumentēts. Nepārprotami baitu budžeta pārrakstījumi tiek ierobežoti diapazonā no 8 MiB līdz 2 GiB. 413 body_exceeds_budget nav pārejoša kļūda: palieliniet šo baitu budžetu, samaziniet OMNIROUTE_CHAT_HARD_MAX_BODY_BYTES vai palieliniet procesa atmiņas ierobežojumu. inflight_bytes_budget izraisīta slodzes nomešana ir īslaicīgs resursu konflikts, un to joprojām var atkārtot. Katram pakalpojumu sniedzējam piemērojamā pieprasījumu biežuma ierobežošana (open-sse/services/rateLimitManager.ts) tiek pārvaldīta atsevišķi ar RATE_LIMIT_MAX_WAIT_MS, RATE_LIMIT_MAX_QUEUE_DEPTH un RATE_LIMIT_AUTO_ENABLE — skatiet .env.example.

Kā pārbaudīt, vai risinājums darbojas: divas reizes īsā laika intervālā palaidiet savu aģentu/cron un pārliecinieties, ka abas izpildes ir veiksmīgas. Pirms labojuma otrā izpilde parasti atgriež 429/401. Pēc labojuma kļūmju gadījumā (ja tādas rodas) mēģinājumi tiek pārredzami atkārtoti un izsaukums tiek pabeigts. Varat arī izpildīt curl /monitoring/health un pakalpojumu sniedzēju savienojumos vērot lauku rateLimitedUntil, kā arī circuitBreakers.providerBreakers[].state attiecīgajiem pakalpojumu sniedzējiem — stāvoklis var būt CLOSED, DEGRADED, OPEN vai HALF_OPEN (skatiet src/shared/utils/circuitBreaker.ts), un pakalpojumu sniedzējs, kura darbība atkārtoti cieš neveiksmi, pārslēgsies CLOSED → DEGRADED → OPEN, pirms atiestatīšanas periods ļaus veikt pārbaudes pieprasījumu (HALF_OPEN).

Ja joprojām redzat 429: šī pakalpojumu sniedzēja aktīvais konts patiešām ir izsmēlis savu kvotu (nevis tikai sasniedzis pieprasījumu biežuma ierobežojumu). OmniRoute informācijas panelī pievienojiet otru tā paša pakalpojumu sniedzēja kontu: Providers → Accounts, vai pievienojiet vēl kādu bezmaksas pakalpojumu sniedzēju (piem., routeway, auggie). Rotācija palīdz tikai pārejošu pieprasījumu biežuma ierobežojumu un 400/401 kļūdu gadījumā; pilnīgai kvotas izsmelšanai ir nepieciešami citi akreditācijas dati vai cits pakalpojumu sniedzējs.

Ja redzat 403 redzes modeļiem (auto/vision, bazaarlink/*): savienotajam kontam nav maksas plāna, kas ietver redzes funkcijas, vai arī API atslēgai nav pietiekamu atļauju. Pakalpojumu sniedzēja informācijas panelī pārbaudiet, vai atslēgas tvērums ietver redzes/multimodālās funkcijas, vai pievienojiet maksas līmeņa kontu un saglabājiet to kā redzes pieprasījumu mērķi.

`npm install` brīdinājumi (ERESOLVE / peer / deprecated)

Palaižot npm install -g omniroute, var tikt parādīts liels daudzums brīdinājumu, piemēram, npm warn ERESOLVE, paziņojumi par vienādranga atkarībām un deprecated ziņojumi. Tie ir sagaidāmi un nekaitīgi. Instalēšana ir izdevusies, ja izvadē redzat added <N> packages.

Lai nerādītu vienādranga atkarību atrisināšanas brīdinājumus, izmantojiet OmniRoute atbalstīto instalēšanas veidu:

npm install -g omniroute --legacy-peer-deps

--legacy-peer-deps nerāda tikai ERESOLVE un paziņojumus par vienādranga atkarībām. Novecojušu pakotņu paziņojumi joprojām būs redzami, jo tos rada netiešās trešo pušu pakotnes; tie nenozīmē, ka instalēšana neizdevās.

Brīdinājumus rada novecojuši vienādranga atkarību diapazoni trešo pušu pakotnēs, kuras OmniRoute nekontrolē:

marked-terminal pieprasa marked >=1 <16, bet atrasts marked@18 — praksē darbojas bez problēmām; augšupstraumes vienādranga atkarības diapazons vienkārši ir novecojis.
deprecated prebuild-install@7.1.3 — netiešs palīgrīks vietējo bināro failu iegūšanai. Tas netiek izmantots piesaistītā wreq-js transporta saistījuma instalēšanai un nenozīmē, ka tīmekļa sīkfailu nodrošinātāja transporta iestatīšana neizdevās.

Nekādas darbības nav nepieciešamas — šos brīdinājumus nevar pilnībā paslēpt, neveidojot augšupstraumes pakotņu atzarus.

Gemini Web un Playwright Chromium

Ja Gemini Web pieprasījums atgriež 503 ar ziņojumu, ka Playwright Chromium nav instalēts, npm pakotne ir pieejama, taču trūkst pārlūkprogrammas binārā faila. Playwright ar nolūku pārlūkprogrammu lejupielādes nodala no npm pakotnes instalēšanas, tādēļ šāda atbilde ir sagaidāma, līdz pārlūkprogramma tiek instalēta.

Globālas npm instalācijas gadījumā instalējiet Chromium no OmniRoute pakotnes direktorija, lai pārlūkprogrammas kešatmiņa piederētu tai pašai Playwright instalācijai:

cd "$(npm root -g)/omniroute"
npx playwright install chromium

Pēc instalēšanas restartējiet OmniRoute un pēc tam atkārtojiet Gemini Web pieprasījumu. Ja palaižat OmniRoute no Docker attēla, izmantojiet -web attēlu (vai runner-web būvējuma mērķi), kurā ir iekļauts Chromium un tā atkarības; pamata attēlā to nav.

Ātrie risinājumi

Problēma	Risinājums
Pirmā pieteikšanās nedarbojas	Iestatiet `INITIAL_PASSWORD` failā `.env` (nav kodā ierakstītas noklusējuma vērtības)
Informācijas panelis tiek atvērts nepareizajā portā	Iestatiet `PORT=20128` un `NEXT_PUBLIC_BASE_URL=http://localhost:20128`
Žurnāli netiek ierakstīti diskā	Iestatiet `APP_LOG_TO_FILE=true` un pārbaudiet, vai ir iespējota zvanu žurnālu tveršana
EACCES: piekļuve liegta	Iestatiet `DATA_DIR=/path/to/writable/dir`, lai aizstātu `~/.omniroute`
Maršrutēšanas stratēģija netiek saglabāta	Atjauniniet uz jaunāko v3.x laidienu (Zod shēmas labojums iestatījumu saglabāšanai tika iekļauts iepriekšējās versijās)
Pieteikšanās avārija / tukša lapa	Pārbaudiet Node.js versiju — skatiet tālāk sadaļu Node.js saderība
`dlopen` / `slice is not valid mach-o file` (macOS)	Palaidiet `cd $(npm root -g)/omniroute/app && npm rebuild better-sqlite3 && omniroute` — skatiet tālāk sadaļu macOS vietējā moduļa pārbūvēšana
Starpniekservera kļūda "fetch failed"	Pārliecinieties, ka starpniekservera konfigurācija ir iestatīta pareizajā līmenī — skatiet tālāk sadaļu Starpniekservera problēmas
Docker `curl: (56) Recv failure: Connection reset by peer`	Iespējams, Docker porta piesaiste izmanto IPv6. Izmantojiet `-p 127.0.0.1:20128:20128`, lai piespiedu kārtā lietotu IPv4, vai testējiet ar `curl -4`. Skatiet tālāk sadaļu Docker IPv6
Antivīruss ievieto `README.md` karantīnā	Kļūdaini pozitīvs rezultāts — skatiet tālāk sadaļu Antivīrusa kļūdaini pozitīvie rezultāti
Kaspersky atzīmē darbvirsmas lietotni kā Trojas zirgu	Uzvedībā balstīts kļūdaini pozitīvs rezultāts neparakstītam instalētājam — skatiet tālāk sadaļu Antivīrusa kļūdaini pozitīvie rezultāti

Antivīrusa kļūdaini pozitīvie rezultāti

Avast/AVG ievieto `README.md` karantīnā ar `MD:HttpRequest-inf[Susp]`

Tas ir kļūdaini pozitīvs rezultāts. Nekas nav inficēts, un nekādas darbības nav jāveic.

Avast un AVG izmanto heiristisku pārbaudi, kas atzīmē vienkārša teksta/Markdown failus, kuros ir daudz HTTP pieprasījumiem līdzīgu saišu. OmniRoute README.md ir iekļauts npm pakotnē (tas ir norādīts package.json → files), tāpēc globālas instalēšanas laikā tas nonāk node_modules/omniroute/README.md — un tajā ir aptuveni 15 http://localhost:20128/... piemēri (MCP HTTP/SSE galapunkti, A2A .well-known URL un curl fragmenti). Ar šādu saišu blīvumu pietiek, lai nostrādātu heiristiskā pārbaude.

Ja tas sākās tikai nesen: faila veids nav mainījies. README tika paplašināta galapunktu tabula (tika pievienoti MCP HTTP + SSE + A2A) un vairāk curl piemēru, tādējādi pārsniedzot slieksni.

Fails ir neaktīva dokumentācija bez jebkāda izpildāma satura. To var droši atjaunot no karantīnas.

Ko darīt:

Apturiet paziņojumus — pievienojiet instalācijas direktoriju sava antivīrusa izņēmumiem (Avast: Settings → Exceptions), norādot globālo node_modules ceļu un/vai OmniRoute datu direktoriju (~/.omniroute/).
Ziņojiet par kļūdaini pozitīvo rezultātu — https://www.avast.com/false-positive-file-form.php, pievienojot karantīnā ievietoto README.md. Šis ir risinājums, kas palīdz visiem, jo ražotāja heiristika pārmērīgi reaģē uz teksta failu.

Kāpēc mēs to „nelabojam” savā pusē: visi piemēri izmanto http://localhost, un localhost nevar izmantot https bez neērtībām, ko rada pašparakstīts sertifikāts. Dokumentācijas sakropļošana, lai apietu viena ražotāja heiristiku, kaitētu visiem lasītājiem tikai tādēļ, lai izdabātu skenera kļūdai.

Kaspersky atzīmē darbvirsmas lietotni kā `PDM:Trojan.Win32.Generic`

Tas ir uzvedības heiristikas izraisīts kļūdaini pozitīvs rezultāts. Nekas nav inficēts. Kaspersky prefikss PDM: nozīmē, ka spriedumu sniedz tā Proactive Defense Module (System Watcher), kas vērtē instalētāja darbības, nevis salīdzina to ar zināmu ļaunprogrammatūru. Kad tas nostrādā, Kaspersky „atritina” visu instalāciju — dzēšot jau ierakstītos failus —, tāpēc lietotne kļūst bojāta vai pazūd.

Atzīmētie faili ir standarta daļas no deklarētām atvērtā pirmkoda atkarībām, kas iekļautas darbvirsmas lietotnē, piemēram:

resources/app/.build/next/node_modules/playwright-<hash>/lib/…/agentParser.js un workerProcessEntry.js — Playwright, pārlūkprogrammas automatizācijas bibliotēka, ko izmanto lietotnē veiktai pakalpojumu sniedzēja pieteikšanās procedūrai un pārlūkprogrammas nodrošinātai tērzēšanai.
resources/app/.build/next/node_modules/@wreq-js/binding-win32-<arch>-msvc-<hash>/wreq-js.win32-<arch>-msvc.node — fiksētās versijas wreq-js vietējais saistījums, ko izmanto pārlūkprogrammas pirkstu nospiedumu atdarinošiem HTTP pieprasījumiem tīmekļa sīkdatņu pakalpojumu sniedzējiem (<arch> ir x64 vai arm64).

Kāpēc tas nostrādā: Windows instalētājs vēl nav parakstīts ar kodparaksta sertifikātu, tāpēc neparakstītam NSIS instalētājam nav nekādas reputācijas un uzvedības heiristikas darbojas ar maksimālu agresivitāti. Apvienojumā ar komplektācijā iekļautu vietējo DLL un simtiem .js failu, kas tiek ierakstīti %LOCALAPPDATA%\Programs\OmniRoute (tostarp Next.js savrupā būvējuma pakotņu direktorijiem ar pievienotu jaucējvērtību), ar to pietiek, lai nostrādātu heiristiskā pārbaude. Kodparakstīšana ir plānota; līdz tās ieviešanai šī problēma var atkārtoties ar jauniem laidieniem.

Ko darīt:

Vispirms pārbaudiet lejupielādēto failu (tas izslēdz faila modificēšanas iespēju). Katram laidienam tiek publicēts latest.yml, kura lauks sha512 (base64) attiecas uz instalētāju OmniRoute.Setup.<version>.exe. PowerShell konsolē no mapes, kurā atrodas instalētājs:
```
$b = [System.Security.Cryptography.SHA512]::Create().ComputeHash(
  [System.IO.File]::ReadAllBytes("$PWD\OmniRoute.Setup.<version>.exe"))
[Convert]::ToBase64String($b)
```
Izvadei jāsakrīt ar latest.yml → sha512. Ja tā nesakrīt, izdzēsiet failu un lejupielādējiet to atkārtoti tikai no GitHub laidienu lapas.
Atjaunojiet un pievienojiet izņēmumu — atjaunojiet karantīnā ievietotos un atritināšanas laikā noņemtos vienumus un pievienojiet izņēmumu ceļam %LOCALAPPDATA%\Programs\OmniRoute (Kaspersky → Settings → Threats and Exclusions), pēc tam instalējiet atkārtoti.
Ziņojiet par kļūdaini pozitīvo rezultātu — https://opentip.kaspersky.com/. Lietotāju iesniegtie ziņojumi par kļūdaini pozitīviem rezultātiem patiešām paātrina pievienošanu atļauto vienumu sarakstam.

Node.js saderība

Pieteikšanās lapa avarē vai parāda kļūdu "Module self-registration"

Cēlonis: Jūs izmantojat Node.js versiju, kas neatbilst OmniRoute apstiprinātajam drošās izpildvides minimālajam līmenim. Visbiežāk tas notiek, ja tiek izmantots vecāks Node 22 vai 24 ielāpa līmenis, kas ir zemāks par OmniRoute pieprasīto drošības labojumu minimumu.

Simptomi:

Pieteikšanās lapā tiek parādīts tukšs ekrāns vai servera kļūda
Konsolē tiek parādīts Error: Module did not self-register vai līdzīgas vietējās saistīšanas kļūdas
Ja izpildvide neatbilst atbalstītajai drošības politikai, pieteikšanās lapā tiek parādīts oranžs brīdinājuma reklāmkarogs ar jūsu Node versiju

Risinājums:

Instalējiet atbalstītu Node.js LTS laidienu (ieteicams: Node.js 24.x):
```
nvm install 24
nvm use 24
```
Pārbaudiet savu versiju: node --version jāparāda v24.0.0 vai jaunāka 24.x LTS līnijas versija
Pārinstalējiet OmniRoute: npm install -g omniroute
Restartējiet: omniroute

Atbalstītās drošās versijas: >=22.22.2 <23 vai >=24.0.0 <27. Node.js 24.x LTS (Krypton) un Node.js 26 tiek pilnībā atbalstīti.

npm v11+: `better-sqlite3` nav instalēts (Cannot find module)

Cēlonis: npm v11 (iekļauts Node.js 24+) pēc noklusējuma bloķē neobligāto atkarību instalēšanas skriptus. Tā kā better-sqlite3 ir norādīts sadaļā optionalDependencies un tam ir nepieciešama vietējā kompilēšana (node-gyp rebuild), npm to izlaiž bez brīdinājuma.

Simptomi:

Serveris startēšanas laikā avarē ar kļūdu Cannot find module 'better-sqlite3'
ls node_modules/better-sqlite3 parāda "No such file or directory"
npm ls better-sqlite3 parāda (empty)

Risinājums:

Apstipriniet instalēšanas skriptus un pārinstalējiet:
```
npm approve-scripts better-sqlite3
npm install
```

Vai instalējiet iepriekš kompilēto pakotni manuāli:

npm pack better-sqlite3@13.0.1
tar -xzf better-sqlite3-*.tgz -C node_modules
mv node_modules/package node_modules/better-sqlite3
rm better-sqlite3-*.tgz

Pārbaudiet, vai tas darbojas: node -e "require('better-sqlite3')(':memory:').close(); console.log('OK')"

macOS: `dlopen` / "slice is not valid mach-o file"

Cēlonis: Pēc globālas npm install -g omniroute instalēšanas pakotnē iekļautais better-sqlite3 vietējais binārais fails var būt kompilēts citai arhitektūrai vai Node.js ABI nekā lokāli izmantotā. Tas bieži notiek macOS vidē (gan Apple Silicon, gan Intel), ja iepriekš kompilētais binārais fails neatbilst jūsu videi.

Simptomi:

Serveris uzreiz pēc startēšanas avarē ar dlopen kļūdu
Kļūda satur slice is not valid mach-o file
Pilns piemērs:

dlopen(/Users/<user>/.nvm/versions/node/v24.14.1/lib/node_modules/omniroute/app/node_modules/better-sqlite3/build/Release/better_sqlite3.node, 0x0001): tried: '...' (slice is not valid mach-o file)

Risinājums — pārkompilējiet savai lokālajai videi (Node.js versijas pazemināšana nav nepieciešama):

cd $(npm root -g)/omniroute/app
npm rebuild better-sqlite3
omniroute

Piezīme: Tādējādi vietējā saistne tiek pārkompilēta atbilstoši jūsu lokālajai Node.js versijai un procesora arhitektūrai, novēršot bināro failu neatbilstību. Oficiāli atbalstītais izpildvides diapazons ir >=22.22.2 <23 vai >=24.0.0 <27 (SUPPORTED_NODE_RANGE failā src/shared/utils/nodeRuntimeSupport.ts, saskaņots ar package.json lauku engines). Node.js 24.x LTS (Krypton) un Node.js 26 tiek pilnībā atbalstīti ar better-sqlite3 v12.x.

Starpniekservera problēmas

Pakalpojuma sniedzēja validācija rāda "fetch failed"

Cēlonis: API atslēgas validācijas galapunkts (POST /api/providers/validate) iepriekš apgāja starpniekservera konfigurāciju, izraisot kļūmes vidēs, kurās nepieciešama maršrutēšana caur starpniekserveri.

Labojums (v3.5.5+): Šī problēma tagad ir novērsta. Pakalpojuma sniedzēja validācija tiek maršrutēta caur runWithProxyContext, automātiski ievērojot pakalpojuma sniedzēja līmeņa un globālos starpniekservera iestatījumus.

Pilnvaras veselības pārbaude neizdodas ar kļūdu "fetch failed"

Cēlonis: Fona OAuth pilnvaras atsvaidzināšana nenoteica starpniekservera konfigurāciju katram savienojumam.

Labojums (v3.5.5+): Pilnvaru veselības pārbaudes plānotājs tagad nosaka starpniekservera konfigurāciju katram savienojumam pirms atsvaidzināšanas mēģinājuma. Atjauniniet uz v3.5.5+.

SOCKS5 starpniekserveris atgriež kļūdu "invalid onRequestStart method"

Cēlonis: Node.js 22 vidē undici@8 dispečers nav saderīgs ar Node iebūvēto fetch() implementāciju.

Labojums (v3.5.5+): Kad ir aktīvs starpniekservera dispečers, OmniRoute tagad izmanto paša undici funkciju fetch(), nodrošinot konsekventu darbību. Atjauniniet uz v3.5.5+.

MITM starpniekserveris WSL vidē: darbvirsmas lietotnes Windows resursdatorā netiek pārtvertas

Cēlonis: MITM starpniekserveris un tā CA sertifikāts tiek instalēti vidē, kurā darbojas OmniRoute. WSL gadījumā šī vide ir Linux viessistēma, savukārt AI darbvirsmas lietotnes (Kiro, Trae, Copilot, Zed, …) darbojas Windows resursdatorā. Resursdatora lietotnes neuzticas vies sistēmas sertifikātu krātuvei un nemaršrutē datplūsmu caur vies sistēmas sistēmas starpniekserveri, tāpēc darbvirsmas datplūsmas pārtveršana nenotiek.

Ieteikums: Darbiniet OmniRoute tieši tajā pašā operētājsistēmā, kurā darbojas pārtveramās darbvirsmas lietotnes (Windows — Windows lietotnēm; analogi macOS/Linux). Ja OmniRoute tiek paturēts WSL vidē, bet mērķis ir resursdatora lietotnes, Windows resursdatorā ir manuāli jāuzticas ģenerētajam CA sertifikātam un katras resursdatora lietotnes tīkla/starpniekservera iestatījumi jānovirza uz WSL starpniekservera galapunktu — šāda konfigurācija netiek atbalstīta un ir trausla.

Pakalpojuma sniedzēju problēmas

"Language model did not provide messages"

Cēlonis: Pakalpojuma sniedzēja kvota ir izsmelta.

Labojums:

Pārbaudiet kvotas uzskaiti informācijas panelī
Izmantojiet kombināciju ar rezerves līmeņiem
Pārslēdzieties uz lētāku/bezmaksas līmeni

Ātruma ierobežošana

Cēlonis: Abonementa kvota ir izsmelta.

Labojums:

Pievienojiet rezerves variantus: cc/claude-opus-4-6 → glm/glm-4.7 → if/qwen3.8-max-preview
Izmantojiet GLM/MiniMax kā lētu rezerves variantu

OAuth pilnvarai beidzies derīguma termiņš

OmniRoute automātiski atsvaidzina pilnvaras. Ja problēmas saglabājas:

Informācijas panelis → Pakalpojuma sniedzējs → Izveidot savienojumu no jauna
Dzēsiet un atkārtoti pievienojiet pakalpojuma sniedzēja savienojumu

Vairāki Kiro konti: otrais konts padara pirmo nederīgu

Cēlonis: Kiro aizmugursistēma katrai OIDC klienta reģistrācijai atļauj tikai vienu aktīvu sesiju. Ja divi konti izmanto vienu un to pašu reģistrēto klientu (savienojumi importēti pirms v3.8.0), viena konta pilnvaras atsvaidzināšana padara nederīgu otra konta atsvaidzināšanas pilnvaru.

Labojums (v3.8.0+): Atkārtoti importējiet ietekmētos savienojumus. Sākot ar v3.8.0, katrs jauns Kiro savienojums, kas izveidots, izmantojot Pilnvaras importēšanu, Google/GitHub sociālo pieteikšanos vai Automātisko importēšanu, automātiski reģistrē savu atsevišķu OIDC klientu. Tādējādi savienojums ir pilnībā izolēts, un viena konta atsvaidzināšana neietekmē nevienu citu kontu.

Savienojumiem, kas tika importēti pirms v3.8.0, nav katram savienojumam atsevišķas klienta reģistrācijas. Šie savienojumi turpina izmantot kopīgo sociālās autentifikācijas atsvaidzināšanas galapunktu. Lai iegūtu izolāciju, izdzēsiet veco savienojumu sadaļā Informācijas panelis → Pakalpojumu sniedzēji un pievienojiet to no jauna, izmantojot jebkuru no trim importēšanas plūsmām.

Pilnīgu informāciju un detalizētus norādījumus par divu Kiro kontu pievienošanu vienlaikus skatiet docs/guides/KIRO_SETUP.md.

Mākoņa problēmas

Mākoņa sinhronizācijas kļūdas

Pārbaudiet, vai BASE_URL norāda uz jūsu darbojošos instanci (piem., http://localhost:20128)
Pārbaudiet, vai CLOUD_URL norāda uz jūsu mākoņa galapunktu (piem., https://omniroute.dev)
Nodrošiniet, lai NEXT_PUBLIC_* vērtības atbilstu servera puses vērtībām

Mākoņa `stream=false` atgriež 500

Simptoms: Unexpected token 'd'... mākoņa galapunktā nestraumētiem izsaukumiem.

Cēlonis: Augšupstraumes pakalpojums atgriež SSE datu slodzi, kamēr klients sagaida JSON.

Pagaidu risinājums: Tiešiem mākoņa izsaukumiem izmantojiet stream=true. Lokālajā izpildvidē ir iekļauts SSE→JSON rezerves mehānisms.

Mākonis rāda, ka savienojums ir izveidots, bet ziņo „Nederīga API atslēga”

Izveidojiet jaunu atslēgu lokālajā informācijas panelī (/api/keys)
Palaidiet mākoņa sinhronizāciju: Iespējot mākoni → Sinhronizēt tagad
Vecas vai nesinhronizētas atslēgas mākonī joprojām var atgriezt 401

Docker problēmas

Docker IPv6 / savienojuma atiestatīšana

Simptomi: curl http://localhost:20128/v1/models atgriež curl: (56) Recv failure: Connection reset by peer. Informācijas panelis un galapunkti bez autentifikācijas darbojas, bet autentificētie galapunkti nedarbojas — tas izskatās pēc autentifikācijas problēmas, taču tā nav.

Cēlonis: docker run -p 20128:20128 publicē portu gan uz 0.0.0.0 (IPv4), gan uz :: (IPv6), taču process konteinerā klausās tikai IPv4. Resursdatoros, kuros localhost vispirms tiek atrisināts kā ::1, savienojums nonāk publicētajā IPv6 portā, aiz kura nav klausītāja → savienojums tiek atiestatīts.

Risinājums:

Ātrā diagnostika: Palaidiet curl -4 http://localhost:20128/v1/models. Ja tas darbojas ar -4, bet nedarbojas bez tā, pastāv IPv6 piesaistes neatbilstība.
Pastāvīgais risinājums: Skaidri piesaistiet IPv4, savā docker run komandā izmantojot -p 127.0.0.1:20128:20128:
```
docker run -d --name omniroute --restart unless-stopped --stop-timeout 40 \
  -p 127.0.0.1:20128:20128 -v omniroute-data:/app/data diegosouzapw/omniroute:latest
```
Tas uzspiež IPv4 piesaisti un arī novērš starpniekservera atklāšanu visās resursdatora saskarnēs.

CLI rīks tiek rādīts kā neinstalēts

Pārbaudiet izpildvides laukus: curl http://localhost:20128/api/cli-tools/runtime/codex | jq
Portatīvajam režīmam: izmantojiet attēla mērķi runner-cli (CLI rīki ir iekļauti komplektā)
Resursdatora montēšanas režīmam: iestatiet CLI_EXTRA_PATHS un montējiet resursdatora bināro failu direktoriju tikai lasīšanas režīmā
Ja installed=true un runnable=false: binārais fails tika atrasts, bet darbspējas pārbaude neizdevās

Ātra izpildvides pārbaude

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}'

Izmaksu problēmas

Augstas izmaksas

Pārbaudiet lietojuma statistiku sadaļā Informācijas panelis → Lietojums
Nomainiet primāro modeli uz GLM/MiniMax
Mazāk svarīgiem uzdevumiem izmantojiet bezmaksas līmeni (Qoder, Kiro)
Iestatiet izmaksu budžetus katrai API atslēgai: Informācijas panelis → API atslēgas → Budžets

Atkļūdošana

Žurnālfailu iespējošana

Iestatiet APP_LOG_TO_FILE=true savā .env failā. Lietojumprogrammas žurnāli tiek ierakstīti direktorijā logs/. Pieprasījumu artefakti tiek glabāti direktorijā ${DATA_DIR}/call_logs/, kad iestatījumos ir iespējots izsaukumu žurnālu konveijers. Kad ir iespējota konveijera tveršana, iestatiet CALL_LOG_PIPELINE_CAPTURE_STREAM_CHUNKS=false, lai izlaistu straumes fragmentu datu slodzes, vai pielāgojiet CALL_LOG_PIPELINE_MAX_SIZE_KB, lai mainītu artefaktu ierobežojumu KB.

Pakalpojumu sniedzēja darbspējas pārbaude

# Darbspējas informācijas panelis
http://localhost:20128/dashboard/health

# API darbspējas pārbaude
curl http://localhost:20128/api/monitoring/health

Izpildvides krātuve

Galvenais stāvoklis: ${DATA_DIR}/storage.sqlite (pakalpojumu sniedzēji, kombinācijas, aizstājvārdi, atslēgas, iestatījumi)
Lietojums: SQLite tabulas failā storage.sqlite (usage_history, call_logs, proxy_logs) + neobligāti ${DATA_DIR}/call_logs/
Lietojumprogrammas žurnāli: <repo>/logs/... (kad APP_LOG_TO_FILE=true)
Izsaukumu žurnālu artefakti: ${DATA_DIR}/call_logs/YYYY-MM-DD/..., kad ir iespējots izsaukumu žurnālu konveijers

Pieprasījumu žurnālu lapas darbība Notīrīt vēsturi notīra call_logs, mantoto request_detail_logs un lokālo ${DATA_DIR}/call_logs/ artefaktu direktoriju.

Ķēdes pārtraucēja problēmas

Pakalpojumu sniedzējs iestrēdzis OPEN stāvoklī

Kad pakalpojumu sniedzēja ķēdes pārtraucējs ir OPEN stāvoklī, pieprasījumi tiek bloķēti līdz atdzišanas perioda beigām.

Risinājums:

Dodieties uz Informācijas panelis → Iestatījumi → Noturība
Pārbaudiet ietekmētā pakalpojumu sniedzēja ķēdes pārtraucēja kartīti
Noklikšķiniet uz Atiestatīt visus, lai atiestatītu visus pārtraucējus, vai gaidiet, līdz beidzas atdzišanas periods
Pirms atiestatīšanas pārbaudiet, vai pakalpojumu sniedzējs patiešām ir pieejams

Pakalpojumu sniedzējs atkārtoti aktivizē ķēdes pārtraucēju

Ja pakalpojumu sniedzējs atkārtoti nonāk OPEN stāvoklī:

Sadaļā Informācijas panelis → Stāvoklis → Pakalpojumu sniedzēju stāvoklis pārbaudiet kļūmju modeli
Dodieties uz Iestatījumi → Noturība → Pakalpojumu sniedzēju profili un palieliniet kļūmju slieksni
Pārbaudiet, vai pakalpojumu sniedzējs nav mainījis API ierobežojumus un vai nav nepieciešama atkārtota autentifikācija
Pārskatiet latentuma telemetriju — liels latentums var izraisīt taimauta kļūmes

Audio transkripcijas problēmas

Kļūda „Neatbalstīts modelis”

Izmantojiet modeļa ID, kura pirmais segments ir pakalpojumu sniedzējs, kam jums ir akreditācijas dati (openai/whisper-1, openrouter/deepgram/nova-3). Lai izmantotu tikai deepgram/nova-3, ir nepieciešama vietējā Deepgram atslēga.
Pārbaudiet, vai pakalpojumu sniedzējs ir savienots sadaļā Informācijas panelis → Pakalpojumu sniedzēji

Transkripcija ir tukša vai neizdodas

Pārbaudiet atbalstītos audio formātus: mp3, wav, m4a, flac, ogg, webm
Pārbaudiet, vai faila lielums nepārsniedz pakalpojumu sniedzēja ierobežojumus (parasti < 25MB)
Pakalpojumu sniedzēja kartītē pārbaudiet pakalpojumu sniedzēja API atslēgas derīgumu

Tulkotāja atkļūdošana

Izmantojiet sadaļu Informācijas panelis → Tulkotājs, lai atkļūdotu formātu tulkošanas problēmas:

Režīms	Kad izmantot
Izmēģinājumu vide	Salīdziniet ievades/izvades formātus blakus — ielīmējiet nesekmīgu pieprasījumu, lai redzētu, kā tas tiek tulkots
Tērzēšanas testētājs	Sūtiet ziņojumus reāllaikā un pārbaudiet pilnu pieprasījuma/atbildes datu kopu, tostarp galvenes
Testēšanas vide	Palaidiet pakešu testus dažādām formātu kombinācijām, lai noteiktu, kuri tulkojumi nedarbojas
Tiešraides pārraugs	Vērojiet pieprasījumu plūsmu reāllaikā, lai atklātu periodiskas tulkošanas problēmas

Biežākās formātu problēmas

Domāšanas tagi neparādās — pārbaudiet, vai mērķa pakalpojumu sniedzējs atbalsta domāšanu, kā arī domāšanas budžeta iestatījumu
Rīku izsaukumi pazūd — daži formātu tulkojumi var noņemt neatbalstītus laukus; pārbaudiet to režīmā Izmēģinājumu vide
Trūkst sistēmas uzvednes — Claude un Gemini sistēmas uzvednes apstrādā atšķirīgi; pārbaudiet tulkojuma izvadi
SDK objekta vietā atgriež neapstrādātu virkni — atrisināts versijā v1.x; atbilžu sanitizētājs noņem nestandarta laukus (x_groq, usage_breakdown utt.), kas izraisa OpenAI SDK Pydantic validācijas kļūmes. Ja joprojām to novērojat versijā v3.x+, lūdzu, iesniedziet problēmas ziņojumu.
GLM/ERNIE noraida system lomu — atrisināts versijā v1.x; lomu normalizētājs nesaderīgiem modeļiem automātiski apvieno sistēmas ziņojumus ar lietotāja ziņojumiem. Ja joprojām to novērojat versijā v3.x+, lūdzu, iesniedziet problēmas ziņojumu.
developer loma netiek atpazīta — atrisināts versijā v1.x; pakalpojumu sniedzējiem, kas nav OpenAI, tā tiek automātiski pārveidota par system. Ja joprojām to novērojat versijā v3.x+, lūdzu, iesniedziet problēmas ziņojumu.
json_schema nedarbojas ar Gemini — atrisināts versijā v1.x; response_format tagad tiek pārveidots par Gemini responseMimeType + responseSchema. Ja joprojām to novērojat versijā v3.x+, lūdzu, iesniedziet problēmas ziņojumu.

Noturības iestatījumi

Automātiskā pieprasījumu biežuma ierobežošana netiek aktivizēta

Automātiskā pieprasījumu biežuma ierobežošana attiecas tikai uz API atslēgu nodrošinātājiem (nevis OAuth/abonementiem)
Pārbaudiet, vai sadaļā Iestatījumi → Noturība → Nodrošinātāju profili ir iespējota automātiskā pieprasījumu biežuma ierobežošana
Pārbaudiet, vai nodrošinātājs atgriež statusa kodus 429 vai galvenes Retry-After

Eksponenciālās atkāpšanās regulēšana

Nodrošinātāju profili atbalsta šādus iestatījumus:

Pamata aizkave — sākotnējais gaidīšanas laiks pēc pirmās kļūmes (noklusējums: 1s)
Maksimālā aizkave — maksimālā gaidīšanas laika robeža (noklusējums: 30s)
Reizinātājs — cik lielā mērā palielināt aizkavi pēc katras secīgās kļūmes (noklusējums: 2x)

Lavīnveida pieprasījumu novēršana

Kad daudzi vienlaicīgi pieprasījumi sasniedz nodrošinātāju ar ierobežotu pieprasījumu biežumu, OmniRoute izmanto mutex + automātisko pieprasījumu biežuma ierobežošanu, lai serializētu pieprasījumus un novērstu kļūmju ķēdes reakciju. API atslēgu nodrošinātājiem tas notiek automātiski.

Tērzēšanas pieprasījumi neizdodas ar 503 / chat_admission_busy

Simptomi:

Tērzēšanas pabeigšanas galapunkts atgriež atkārtojamu 503 atbildi, kuras kļūdas kods ir chat_admission_busy.
Atbildē ir ietverts Retry-After. Kopš #12135 vērtība tiek iegūta no novērotā noslogojuma — tiek izmantota lielākā no OMNIROUTE_CHAT_ADMISSION_QUEUE_MS loga daļas, ko pieprasījums jau ir gaidījis, un laika, cik ilgi ir turētas pašreizējās resursietilpīgo pieprasījumu nomas — noapaļota uz augšu līdz veselām sekundēm un ierobežota līdz 60. Ja piekļuves vārteja nav noslogota, tiek saglabātas vēsturiskās minimālās vērtības: 2 sekundes baitos balstītajam ceļam un 1 sekunde struktūrā balstītajam ceļam (kas ietver arī reason: "structure_limit").
Tas var notikt, kamēr vēl tiek izpildīts cits resursietilpīgs tērzēšanas pieprasījums vai ilgstoša straumēšanas atbilde.

Baitos balstītās atbildes pamatteksts ir:

{
  "error": {
    "message": "Chat admission capacity is temporarily unavailable. Retry shortly.",
    "type": "server_error",
    "code": "chat_admission_busy"
  }
}

Struktūrā balstītā atbilde izmanto to pašu tipu un kodu ar ziņojumu Local chat admission capacity is busy for this structurally heavy request; upstream provider routing was not attempted. Retry shortly. un reason: "structure_limit". Izmantojot noklusējuma sliekšņus, pieprasījums ir strukturāli resursietilpīgs, ja tajā ir vismaz 200 ziņojumi, vismaz 64 rīki vai vismaz 32,000 aplēstie tokeni, vai ja ierobežotā struktūras novērtēšana sasniedz savas robežas — 10,000 apmeklētu mezglu vai dziļumu 12.

Cēlonis: Tā ir apzināta slodzes nomešana OmniRoute iekšienē, nevis augšupstraumes nodrošinātāja kļūme. Katrs process izmanto procesam lokālu aizsargmehānismu, lai rezervētu ierobežotu resursietilpīgo pieprasījumu apstrādes kapacitāti, pirms tiek saglabāts un parsēts liels pieprasījuma pamatteksts. Resursietilpīga pieprasījuma noma paliek aktīva visu SSE atbildes darbības laiku.

#503-izplatīšanās: pirms šī labojuma aizsargmehānisms ierobežoja vienlaicīgumu līdz fiksētam pieprasījumu SKAITAM (OMNIROUTE_CHAT_MAX_HEAVY_IN_FLIGHT, noklusējums 1) neatkarīgi no resursdatora atmiņas, tāpēc programmēšanas aģentu izvēršana (vairāki apakšaģenti/CLI, pamatteksti parasti > 256 KB) samazināja faktisko vienlaicīgumu līdz ~1 un pilnīgi normālas slodzes apstākļos izraisīja 503 kļūdas. Tagad aizsargmehānisms pašregulējas: tā darbību nosaka automātiski atvasināts ienākošo BAITU budžets (OMNIROUTE_CHAT_MAX_INFLIGHT_BYTES), kura lielums tiek aprēķināts no procesa faktiskā atmiņas ierobežojuma, un tas ņem vērā arī aktuālu resursu noslodzes signālu — tādējādi slodze tiek nomesta tikai tad, kad resursdatorā tiešām trūkst atmiņas, nevis tikai tāpēc, ka vienlaikus ieradies vairāk nekā viens resursietilpīgs pieprasījums. Iepriekšējais skaita ierobežojums (OMNIROUTE_CHAT_MAX_HEAVY_IN_FLIGHT) joprojām tiek ievērots, taču tikai tad, ja to iestatāt tieši.

Kad kapacitāte ir aizņemta, resursietilpīgs pieprasījums vispirms gaida līdz OMNIROUTE_CHAT_ADMISSION_QUEUE_MS (noklusējums ir RATE_LIMIT_MAX_WAIT_MS; 0 atspējo gaidīšanu), lai atbrīvotos vieta, un tikai pēc tam atgriež atkārtojamo 503 atbildi. Ierobežotā gaidīšana pastāv tādēļ, lai aģentu tipa klienti (OpenCode, Claude Code, Cursor), kas vienlaicīgi izvērš resursietilpīgus apakšpieprasījumus, serializētu šo pieprasījumu vilni, nevis iztērētu visu atkārtošanas budžetu tūlītējiem noraidījumiem un pārtrauktu darbību uzdevuma vidū. Pašreizējais resursietilpīgo pieprasījumu nomu noslogojums, aprēķinātais baitu budžets un aktuālais noslodzes smagums ir pieejami sadaļā GET /api/monitoring/health → chatAdmission (inflightBytes, maxInflightBytes, budgetSource, pressureSeverity, countCapEnabled) — pārbaudiet tos pirms jebkura vides mainīgā mainīšanas. Iestatījumi → Noturība → Pieprasījumu rinda → Vienlaicīgi pieprasījumi to nekontrolē; šis iestatījums pārvalda atsevišķu nodrošinātāja pieprasījumu rindas mehānismu.

Labojums:

Vispirms atkārtojiet pieprasījumu. Klientiem jāievēro Retry-After un jāizmanto atkāpšanās, nevis nekavējoties jāatkārto pieprasījums.
Pirms kaut ko regulējat, pārbaudiet /api/monitoring/health → chatAdmission. countCapEnabled: false un pietiekami liels maxInflightBytes nozīmē, ka automātiski atvasinātais budžets jau darbojas pareizi; pressureSeverity vērtība high/critical nozīmē, ka resursdatorā tiešām trūkst atmiņas — to nevar novērst ar piekļuves vides mainīgo; nepieciešams vairāk RAM vai mazāka darba slodze.
Tikai tad, ja /api/monitoring/health rāda, ka automātiski atvasinātais budžets jūsu resursdatoram tiešām ir pārāk mazs (tas notiek reti — tas jau pielāgojas videi no konteineriem līdz fiziskiem serveriem), pārrakstiet to tieši ar OMNIROUTE_CHAT_MAX_INFLIGHT_BYTES, nevis atgriezieties pie mantotā pieprasījumu skaita ierobežojuma.

Autoritatīvos piekļuves iestatījumus skatiet vides mainīgo atsaucē.

Izvēles RAG / LLM kļūmju taksonomija (16 problēmas)

Daži OmniRoute lietotāji izvieto vārteju pirms RAG vai aģentu stekiem. Šādos iestatījumos bieži novērojama dīvaina situācija: OmniRoute šķiet darba kārtībā (pakalpojumu sniedzēji ir pieejami, maršrutēšanas profili darbojas, nav ātruma ierobežojumu brīdinājumu), taču gala atbilde joprojām ir nepareiza.

Praksē šos incidentus parasti izraisa pakārtotais RAG konveijers, nevis pati vārteja.

Ja vēlaties kopīgu terminoloģiju šo kļūmju aprakstīšanai, varat izmantot WFGY ProblemMap — ārēju teksta resursu ar MIT licenci, kurā definēti sešpadsmit regulāri sastopami RAG / LLM kļūmju modeļi. Augstā līmenī tas aptver:

izguves novirzi un bojātas konteksta robežas
tukšus vai novecojušus indeksus un vektoru krātuves
iegulumu un semantikas neatbilstību
uzvedņu izveides un konteksta loga problēmas
loģikas sabrukumu un pārlieku pašpārliecinātas atbildes
garu ķēžu un aģentu koordinācijas kļūmes
vairāku aģentu atmiņas un lomu novirzi
izvietošanas un sāknēšanas secības problēmas

Ideja ir vienkārša:

Izmeklējot nepareizu atbildi, fiksējiet:
- lietotāja uzdevumu un pieprasījumu
- OmniRoute maršruta vai pakalpojumu sniedzēju kombināciju
- jebkādu pakārtoti izmantoto RAG kontekstu (izgūtos dokumentus, rīku izsaukumus utt.)
Piesaistiet incidentu vienam vai diviem WFGY ProblemMap numuriem (No.1 … No.16).
Saglabājiet numuru savā informācijas panelī, darbību rokasgrāmatā vai incidentu uzskaites sistēmā blakus OmniRoute žurnāliem.
Izmantojiet atbilstošo WFGY lapu, lai izlemtu, vai jāmaina RAG steks, izguves komponents vai maršrutēšanas stratēģija.

Pilns teksts un konkrēti risinājumi ir pieejami šeit (MIT licence, tikai teksts):

WFGY ProblemMap README

Varat ignorēt šo sadaļu, ja aiz OmniRoute neizmantojat RAG vai aģentu konveijerus.

v3.8.0 zināmās problēmas

Problēmas, kas attiecas tieši uz v3.8.0 laidienu, un to pašreizējie pagaidu risinājumi. Ja labojums tiks iekļauts kādā vēlākā ielāpa laidienā, ieraksts tiks atjaunināts vai noņemts.

Devin CLI autentifikācijas kļūmes

Simptomi:

Izsaucot rīkus, kuru pamatā ir Devin, tiek parādīts "Devin CLI not found" vai "auth failed"
CLI izpildlaika pārbaude ziņo installed=false

Cēloņi:

CLI_DEVIN_BIN norāda uz ceļu, kas nepastāv
Devin CLI nav instalēts resursdatorā

Labojums:

Instalējiet Devin CLI savai platformai
Failā .env iestatiet CLI_DEVIN_BIN=/usr/local/bin/devin (vai faktisko ceļu)
Restartējiet OmniRoute un atkārtoti pārbaudiet sadaļā Informācijas panelis → CLI rīki

Modeļa gaidstāves režīms ir iestrēdzis (manuāla atiestatīšana)

Simptomi:

Modelis joprojām tiek rādīts gaidstāves režīmā pat pēc tā beigu laika
Kombinētā maršrutēšana joprojām izlaiž modeli, lai gan laikspiedols ir pagātnē

Manuāla atiestatīšana:

Informācijas panelis: Iestatījumi → Modeļu gaidstāves režīmi → attiecīgajā kartītē noklikšķiniet uz Atkārtoti iespējot
API: DELETE /api/resilience/model-cooldowns ar pārvaldības autentifikācijas galvenēm

Command Code pakalpojumu sniedzēja savienojuma izveide neizdodas ar 403

Simptomi:

Pārbaudot savienojumu ar Command Code pakalpojumu sniedzēju, tiek saņemts 403
Pēc pakalpojumu sniedzēja atkārtotas pievienošanas tā kartītē tiek rādīts "unauthorized"

Cēlonis: OAuth plūsma netika pabeigta (atpakaļizsaukums netika saņemts vai marķieris netika saglabāts).

Labojums:

Palaidiet omniroute providers no CLI, lai atkārtoti aktivizētu OAuth plūsmu, vai
Atkārtoti palaidiet OAuth sadaļā Informācijas panelis → Pakalpojumu sniedzēji → Command Code → Atkārtoti izveidot savienojumu

ModelScope atgriež agresīvus 429 gaidstāves režīmus

Simptomi:

Pēc neliela pieprasījumu uzplūda ModelScope tiek noteikti ļoti īsi vai tūlītēji gaidstāves režīmi
Kombinētā maršrutēšana izlaiž ModelScope agrāk, nekā paredzēts

Cēlonis: ModelScope nosūta pakalpojumu sniedzējam specifiskas Retry-After galvenes. Versijā v3.8.0 ir iekļauta īpaša šo galveņu apstrāde, tādēļ vecākas versijas tās kļūdaini interpretē kā vispārīgas ātruma ierobežojuma norādes.

Labojums:

Pārliecinieties, ka izmantojat v3.8.0 vai jaunāku versiju
Pārbaudiet, vai sadaļā Iestatījumi → Noturība ir iespējots pārslēgs useUpstream429BreakerHints

Ražošanas vidē trūkst OMNIROUTE_WS_BRIDGE_SECRET

Simptomi:

Darbinot attālā ražošanas resursdatorā, katrs Codex/Responses WebSocket tilta pieprasījums saņem 401
WebSocket tilta rokasspiediens tiek aizvērts uzreiz pēc savienojuma izveides

Cēlonis: Ražošanas vidē trūkst vides mainīgā OMNIROUTE_WS_BRIDGE_SECRET.

Labojums:

Ģenerējiet nejaušu noslēpumu: openssl rand -hex 32
Ražošanas servera vidē iestatiet OMNIROUTE_WS_BRIDGE_SECRET=<random-secret> (un arī jebkurā klientā, kas sazinās ar tiltu)
Restartējiet OmniRoute

Responses API: fona režīms pazemināts uz sinhronu režīmu

Simptomi:

Žurnālā tiek reģistrēts brīdinājums: background mode degraded to synchronous
background: true pieprasījums atgriež parastu sinhronu atbildi, nevis fona darba turi

Cēlonis: Versijā v3.8.0 Responses API parametrs background: true apzināti tiek pazemināts uz sinhronu izpildi, vienlaikus izvadot brīdinājumu. Pilna asinhrona izpilde fonā ir plānota nākotnē.

Labojums:

Pielāgojiet klientu, lai tas veiktu izsaukumu bez background, vai
Gaidiet vēlāku laidienu, kurā būs iekļauts pilns asinhronais fona režīms (sekojiet izmaiņu žurnālam)

Lēna palaišana / gatavības taimauts

Ja CLI izvada ⚠ Server did not respond within 60s, bet serveris faktiski darbojas, gatavības pārbaudei atvēlētais laiks jūsu vidē ir pārāk īss.

Tas bieži notiek Windows vidē (pretvīrusu programmatūras, failu sistēmas pārraugi) vai konteineros ar lielu palaišanas darba slodzi.

Risinājums — palieliniet atvēlēto laiku:

# Izmantojot vides mainīgo (saglabājas starp palaišanas reizēm):
export OMNIROUTE_READY_TIMEOUT_MS=180000   # 3 minūtes
omniroute serve

# Izmantojot CLI karodziņu (vienai reizei):
omniroute serve --ready-timeout 180000

Noklusējuma vērtība ir 60 000 ms (60 s). Brīdinājumam ir tikai informatīvs raksturs; serveris turpina palaišanu fonā un būs sasniedzams, tiklīdz palaišana būs pabeigta.

Pilnu informāciju par OMNIROUTE_READY_TIMEOUT_MS skatiet failā docs/reference/ENVIRONMENT.md.

Joprojām neizdodas?

GitHub problēmas: github.com/diegosouzapw/OmniRoute/issues
Arhitektūra: Iekšējo informāciju skatiet failā docs/architecture/ARCHITECTURE.md
API atsauce: Visus galapunktus skatiet failā docs/reference/API_REFERENCE.md
Veselības informācijas panelis: Sistēmas statusu reāllaikā skatiet sadaļā Informācijas panelis → Veselība
Tulkotājs: Lai atkļūdotu formāta problēmas, izmantojiet sadaļu Informācijas panelis → Tulkotājs

60 KiB Raw Blame History

Troubleshooting (Latviešu)

Ātrā uzziņa

Detalizēta problēmu novēršana

Bezmaksas pakalpojumu sniedzēju pieprasījumu biežuma ierobežošana (429 / 400 / 401)

npm install brīdinājumi (ERESOLVE / peer / deprecated)

Gemini Web un Playwright Chromium

Ātrie risinājumi

Antivīrusa kļūdaini pozitīvie rezultāti

Avast/AVG ievieto README.md karantīnā ar MD:HttpRequest-inf[Susp]

Kaspersky atzīmē darbvirsmas lietotni kā PDM:Trojan.Win32.Generic

Node.js saderība

Pieteikšanās lapa avarē vai parāda kļūdu "Module self-registration"

npm v11+: better-sqlite3 nav instalēts (Cannot find module)

macOS: dlopen / "slice is not valid mach-o file"

Starpniekservera problēmas

Pakalpojuma sniedzēja validācija rāda "fetch failed"

Pilnvaras veselības pārbaude neizdodas ar kļūdu "fetch failed"

SOCKS5 starpniekserveris atgriež kļūdu "invalid onRequestStart method"

MITM starpniekserveris WSL vidē: darbvirsmas lietotnes Windows resursdatorā netiek pārtvertas

Pakalpojuma sniedzēju problēmas

"Language model did not provide messages"

Ātruma ierobežošana

OAuth pilnvarai beidzies derīguma termiņš

Vairāki Kiro konti: otrais konts padara pirmo nederīgu

Mākoņa problēmas

Mākoņa sinhronizācijas kļūdas

Mākoņa stream=false atgriež 500

Mākonis rāda, ka savienojums ir izveidots, bet ziņo „Nederīga API atslēga”

Docker problēmas

Docker IPv6 / savienojuma atiestatīšana

CLI rīks tiek rādīts kā neinstalēts

Ātra izpildvides pārbaude

Izmaksu problēmas

Augstas izmaksas

Atkļūdošana

Žurnālfailu iespējošana

Pakalpojumu sniedzēja darbspējas pārbaude

Izpildvides krātuve

Ķēdes pārtraucēja problēmas

Pakalpojumu sniedzējs iestrēdzis OPEN stāvoklī

Pakalpojumu sniedzējs atkārtoti aktivizē ķēdes pārtraucēju

Audio transkripcijas problēmas

Kļūda „Neatbalstīts modelis”

Transkripcija ir tukša vai neizdodas

Tulkotāja atkļūdošana

Biežākās formātu problēmas

Noturības iestatījumi

Automātiskā pieprasījumu biežuma ierobežošana netiek aktivizēta

Eksponenciālās atkāpšanās regulēšana

Lavīnveida pieprasījumu novēršana

Tērzēšanas pieprasījumi neizdodas ar 503 / chat_admission_busy

Izvēles RAG / LLM kļūmju taksonomija (16 problēmas)

v3.8.0 zināmās problēmas

Devin CLI autentifikācijas kļūmes

Modeļa gaidstāves režīms ir iestrēdzis (manuāla atiestatīšana)

Command Code pakalpojumu sniedzēja savienojuma izveide neizdodas ar 403

ModelScope atgriež agresīvus 429 gaidstāves režīmus

Ražošanas vidē trūkst OMNIROUTE_WS_BRIDGE_SECRET

Responses API: fona režīms pazemināts uz sinhronu režīmu

Lēna palaišana / gatavības taimauts

Joprojām neizdodas?

60 KiB

Raw Blame History

`npm install` brīdinājumi (ERESOLVE / peer / deprecated)

Avast/AVG ievieto `README.md` karantīnā ar `MD:HttpRequest-inf[Susp]`

Kaspersky atzīmē darbvirsmas lietotni kā `PDM:Trojan.Win32.Generic`

npm v11+: `better-sqlite3` nav instalēts (Cannot find module)

macOS: `dlopen` / "slice is not valid mach-o file"

Mākoņa `stream=false` atgriež 500