Troubleshooting and support

Save the error code and request time first, then make one small comparison. Avoid repeated key regeneration, changing multiple settings at once or unlimited retries.

Check in order

1. Protocol and address: OpenAI usually uses /v1, Anthropic the domain root, and Gemini /v1beta as the base URL. SDKs append endpoints; avoid duplicate paths.
2. Authentication: Confirm the running client sends the key. A saved setting or a terminal variable does not prove the client process inherited it.
3. Access: Check the exact model ID, key group, balance and key status. See Keys and groups.
4. Request: Compare a short text request with minimal parameters, without unnecessary images, tools or extensions. Save existing settings first.
5. Status: Inspect the corresponding model/group status. If channel monitoring is available in the console, use it as supporting evidence, not a guarantee for every call.

Error reference

HTTP status is only a direction. The specific response error code and message take priority.

Symptom	Possible area	Next step
400	Format, parameters, context length or upstream rejection	Read the message; simplify and correct the request before retrying
401 / API_KEY_REQUIRED	Authentication not recognized	Check active provider, auth method and process environment; do not assume the key is invalid
Other 401	Key spelling, revocation or auth method	Check the error code and key status
403	Permissions, balance, account status or safety policy	Follow the error details; do not bypass safety controls
404	Endpoint construction, protocol or model route	Look for duplicated /v1 or /responses; match client and model protocol
429	Frequency, concurrency or upstream rate limits	Reduce load, respect Retry-After when present, and use bounded backoff
502 / 503 / 504	Upstream failure, unavailable scheduling capacity or timeout	Save time and response details, check the matching group; status alone does not prove a site-wide outage
Timeout / broken stream	Local network, intermediaries, client timeout or upstream interruption	Check Usage before deciding to send a new request

Retrying a timeout

A timeout does not prove that a request was not executed, and a broken stream does not prove that generation or billing did not occur. Check Usage for the matching request. Records can be delayed; no immediate record is not proof that the upstream did nothing. Automatic retries may create new requests and charges, especially for images, video and long contexts.

Correct auth, permission and parameter errors before retrying. Respect rate-limit guidance and cap retry attempts; stop and contact support after repeated failures. Do not assume an unverified idempotency parameter prevents duplicate charges.

Contact support

Use a support ticket if the console offers it, or contact admin@nekocloud.vip / https://t.me/dnalec . Include:

Request time and timezone:
Client and version:
Endpoint (without keys or sensitive query parameters):
Model ID and group:
HTTP status / error code:
Request ID, if available:
Streaming and reproducibility:
Checks already performed:
Matching usage record / order number, if relevant:

Do not include API keys, Authorization headers, cookies, login tokens, full auth.json files or sensitive conversation content. Redact screenshots too.