Troubleshooting

On Linux, also see Linux build: known rough edges — the tray, a second launch, and where pass-cli and op have to be installed.

A funnel source shows an error after Refresh. The message is the upstream's. A route-backed source also needs its route to exist and be enabled.

A funnel exposes no tools. Check the source's Tools mode — under Include with nothing ticked, nothing is exposed. Press Refresh on the source first to populate the list.

An upstream returns 200 but the client reports no reply. The activity log annotates non-JSON responses, e.g. <- 200 [text/html] for POST /app/foo. That usually means the upstream served a sign-in or landing page instead of running its handler — check its deployment settings and whether it accepts your token.

Requests get 403. The endpoint's proxy key is missing, wrong, expired, or was regenerated — or the key belongs to a different route or funnel, which opens nothing here. Copy the key from the row of the endpoint you are calling: the Routes tab for a route, the MCP Funnel tab for a funnel. The activity log names which endpoint refused and why.

Connections are dropped with no status code at all, since enabling mTLS. The failure is in the TLS handshake, which is over before any HTTP exists to answer with. Either the client is presenting no certificate or the wrong one, it is still calling http:// at a listener that now answers https://, or the certificate has expired — the Settings tab shows the date, and the activity log names which of these it was. What the client reports depends on its TLS stack; the common ones are listed under What each failure looks like.

schannel: AcquireCredentialsHandle failed: SEC_E_UNKNOWN_CREDENTIALS from curl. Not a wrong password, whatever it sounds like. Windows' own curl.exe is built against Schannel, which cannot load a client certificate from a .pfx file: name it by store reference instead. See Pointing a client at it, steps 3 and 4.

mac verify failure from Node. The PFX password is wrong. Thrown by https.request before any connection is attempted, so an 'error' handler does not catch it.

DEPTH_ZERO_SELF_SIGNED_CERT from Node. The trust anchor never reached the client: no ca: in the options and no NODE_EXTRA_CA_CERTS. Installing the root into Windows does nothing for Node.

A path that used to work now 403s instead of 404ing. A request to a path belonging to no route and no funnel has no key to check against and is refused rather than answered, so which prefixes exist cannot be discovered by watching status codes.

A route 502s. The activity log records YARP's reason. Confirm the upstream base URL is reachable and https.

An upstream returns 401 and you cannot tell which credential it objected to. A 401 does not say, so all of the route's credentials are flagged. Set a Test endpoint on each and use the Test button to narrow it down — that reports per-credential, which a proxied request cannot.

1Password stops answering, and restarting 1Password does not help. Its integration channel is only opened at 1Password startup, and it is not opened at all if another process holds op_sdk_ipc_client.dll at that moment — a defect on 1Password's side (ipc-client#9). Quit both, start 1Password, then RavensPort. RavensPort no longer touches that library while 1Password is closed, so the start-at-login case cannot happen; a 1Password restarted mid-session still requires the order above, and RavensPort says so instead of failing silently. A service account token avoids the whole problem — it never loads that library.

1Password says the CLI "is not signed at all", but it plainly is. WinGet installs op.exe as a symlink in its Links directory, and that is the copy on PATH. A symlink is a zero-byte reparse point carrying no signature of its own, so the trust check was inspecting an empty file. RavensPort now resolves the link and verifies the binary behind it. A link that cannot be followed is reported as exactly that — temporary, and not an accusation that the vendor binary was tampered with — and service-account mode falls back to the in-process SDK rather than failing the connection.

RavensPort keeps raising 1Password prompts every few seconds. Fixed in 4.3.0: a declined authorization was retried on a timer, and reaching the vault is what raises the prompt. A decline now stops the retries until you press I've unlocked it — save now.

An API key looks right but is always rejected. Check the placement, not the key: a valid key in the wrong header is as broken as a wrong one, and Test reports both as 401. Also check for a stray line break — a key with one is refused before it reaches the wire, and the activity log says NOT ATTACHED for that entry.

A client credentials grant answers invalid_client for an ID and secret you know are right. Providers disagree about where the pair belongs, and the one that wants the other place says only this. Toggle Send client credentials in request body and try again — the activity log records which placement each attempt used.

A service account gets a token, but every API call returns 403. Almost always the scopes. Google issues a token for a scopeless or wrongly-scoped assertion without objecting, and the refusal only arrives at the API. If you set an Impersonated user, the same scopes must also be granted to the service account's client ID under Admin console → Security → API controls → Domain-wide delegation — without that, Google answers unauthorized_client, which the activity log records verbatim.

A GitHub credential shows "Connected · no expiry". That is correct, not a missing value. An OAuth App token has no expires_in and no refresh token, and GitHub does not age it out.

A device code request is refused with unauthorized_client. The flow is not switched on for that client. GitHub needs Enable Device Flow ticked in the OAuth App's settings; Google issues device codes only to a client registered as TVs and Limited Input devices. Neither is the default, and the client ID is otherwise perfectly valid — which is why the error names the client.

The device code was never approved and the flow gave up. Codes expire, usually in 10-15 minutes; the status bar shows the deadline while it waits. Press Connect again for a fresh one. Polling stops on its own at that point — it does not keep hitting the provider.

Edit this page on the wiki Request support · Report vulnerabilities privately