docs: explain the 403 invalid_token case

Clients relied on /openrouter/ having no token check; v0.2.0 applies the
guard to every prefix, so the missing header now shows up everywhere.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -184,6 +184,41 @@ For OpenAI-compatible SDKs set `baseURL` to `https://proxy.bildme.ru/deepseek` a
 
 ---
 
+## Troubleshooting
+
+### `403 {"error":"invalid_token"}` on every path
+
+The proxy answered, not the upstream — `X-Proxy-Token` is missing or wrong. The body is the proxy's own format; a real upstream error looks different (DeepSeek: `{"error":{"message":...,"type":...}}`).
+
+The guard applies to **every** prefix. Before v0.2.0 `/openrouter/` was the one route without a token check — that exception is gone, so clients that relied on it must send the header too.
+
+```bash
+curl -H "X-Proxy-Token: $PROXY_SECRET" \
+     -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
+     https://proxy.bildme.ru/deepseek/user/balance
+```
+
+For OpenAI-compatible SDKs put it in the default headers, next to `baseURL`:
+
+```go
+option.WithBaseURL("https://proxy.bildme.ru/deepseek"),
+option.WithHeader("X-Proxy-Token", os.Getenv("PROXY_SECRET")),
+```
+
+### `403 {"error":"ip_not_allowed"}`
+
+The caller's source IP is not in `ALLOWED_CIDR`. Check the effective list:
+
+```bash
+docker exec api-proxy cat /etc/caddy/matchers.caddy
+```
+
+### Upstream errors pass through unchanged
+
+`401`, `404` or `5xx` with an upstream-shaped JSON body means the proxy did its job and the upstream rejected the request — check the API key, not the proxy.
+
+---
+
 ## Monitoring
 
 ```bash