DOCUMENTATION

The app does not open (404, 403, 502)

The vendor opens the public address, signs in, and gets an error page instead of the app.

Symptom

After signing in, the browser shows a short error page. The number on it is the diagnosis: 404 means the address matched nothing, 403 means the request was recognised and refused, 502 means it was allowed but the connector could not reach the app. A certificate warning before any page, or a login that keeps returning to itself, are the two self-hosted variants at the end.

Check these first

  1. Read the number on the error page and the reason line under it. A 403 names its reason (no grant, pending approval, outside hours, denied, expired); that line alone settles half of this page.
  2. Under Infrastructure → Resources, find the resource and look at its health column: Reachable or Unreachable. Unreachable with a 502 points straight at the connector's side.
  3. Under Access, use Check access with the vendor and the resource. It evaluates the same rules the proxy applies and tells you which one refuses.

Possible causes

404: the hostname matches no resource

How to tell: A plain 404 before or after login. The address in the bar differs from the resource's hostname by a letter, the resource was deleted, or a custom (BYO) domain was entered but never verified.

Fix: Open the resource under Infrastructure → Resources and compare the hostname shown there with what the vendor typed; send them the exact address from the console. On a custom domain, press the verify action on the resource and make sure the domain's A record points at the server. How hostnames are built is in the public hostname.

403: no grant, pending approval or outside the window

How to tell: The 403 page names one of: no grant, pending approval, outside hours, denied, expired. Check access in the console shows the same verdict for that user and resource.

Fix: Each reason has one place to act. No grant: create one under Access (see granting access). Pending: an Admin or Operator approves it under Access → Pending requests (see access requests). Outside hours: the grant's weekly schedule is evaluated in the grant's own time zone; widen it or check the zone. Expired or denied: a new grant is needed; the old one is kept for the audit trail.

403: source-IP allowlist

How to tell: The vendor is refused on every resource, while another vendor on another network gets in. The vendor works from home, a mobile hotspot or a different office than the one you listed.

Fix: Under Infrastructure → Policy, read the Vendor source-IP allowlist. It is matched against the vendor's real public address on every request, so the vendor's current network must fall inside one of the CIDRs. Add it, or clear the list if you do not need the restriction. The console itself is never gated by this list, so you cannot lock yourself out (see source-IP allowlist).

502: the connector cannot reach the internal address

How to tell: A 502 after login, and the resource shows Unreachable. The internal address has the wrong IP or port, the app itself is down, or a firewall sits between the connector host and the app.

Fix: Test from the connector host, not from your laptop: curl -sI http://10.0.5.20:8080 with the resource's internal address. The address is the one the connector reaches, not one the browser could. If curl fails there, fix the app or the network; if it works, check the connector is online at all (see connector shows offline).

502: ALLOWED_TARGETS or the egress policy blocks it

How to tell: A 502 although curl from the connector host succeeds. The connector's log shows a denied dial, and the Denied attempts counter on its page rises each time the vendor retries.

Fix: The connector dials only what its boundary allows. Check two places: the ALLOWED_TARGETS variable on the container (a CIDR, host or host:port list), and the Egress policy on the connector's page in the console. A target must satisfy both. Add the resource's internal address to whichever one excludes it; the console policy can only narrow the container's list, never widen it (see egress boundary).

Certificate error (self-hosted)

How to tell: On your own server only. The browser warns about the certificate before any page loads, while the console at manager.… opens cleanly.

Fix: Per-app certificates are issued on first visit, but only for hostnames that are real resources and only if the wildcard *.access.<your-domain> A record points at the server. Run Infrastructure → Custom domain → Verify DNS; red means the wildcard record is missing or still propagating, which takes minutes. Then confirm the hostname exists as a resource (see verify DNS and TLS).

Login loop: COOKIE_DOMAIN (self-hosted)

How to tell: On your own server only. The vendor signs in successfully at the console, is sent to the app address, and lands back on the login page, as many times as they try.

Fix: The session cookie is set by the console and must also be readable on every <app>.access.<your-domain>. That only works when COOKIE_DOMAIN in .env is the leading-dot form, .access.<your-domain>. Correct it and restart the manager container (see deploy files and .env).

Every allow and every deny on this path is written to the audit log. When a vendor reports a refusal, Audit shows the exact decision and reason with a timestamp, without reproducing it.

If it is still not solved

  • The exact error number and the reason line on the page
  • The resource's hostname and internal address as shown in the console
  • The Check access result for that user and resource
  • The output of curl against the internal address from the connector host
  • The matching Audit entry with its timestamp

Was this article helpful?