Skip to content
Edgible Docs

Why can't I reach my app?

Someone reports that your application “doesn’t load,” or you see a browser error where a working endpoint used to be. The failure almost always falls into one of a few buckets. This page maps the symptom you see to the cause, and to the fix.

Edgible’s gateway terminates public traffic before it ever reaches your workload. When it refuses a request, it does so in one of the ways below — each is deliberate, and each looks different to the client.

”No application at this address”

Section titled “”No application at this address””

Symptom: Opening http://your-host/ returns a plain page reading No application at this address (HTTP 404).

Cause: The edge does not recognise this hostname. Either no application publishes it, the application was deleted, or the hostname is misspelled.

Check:

  • Confirm the application is deployed and its access entry lists this exact hostname.
  • Check for typos — api.example.com and api.exemple.com are different hosts.
  • If you just created the application, allow a moment for DNS and certificate provisioning to finish.

”This application is temporarily unavailable”

Section titled “”This application is temporarily unavailable””

Symptom: http://your-host/ returns This application is temporarily unavailable (HTTP 503), and HTTPS refuses to connect.

Cause: The hostname is a known application, but it is currently suspended. A suspended application is withdrawn from the edge — its traffic is not forwarded — until it is resumed. Your workload itself is untouched; only public access is paused.

Check: Suspension is an administrative action. If you did not expect it, contact whoever administers your organization. Once the application is resumed, the 503 clears on its own.

HTTPS just fails to connect

Section titled “HTTPS just fails to connect”

Symptom: https://your-host/ shows a connection reset, a TLS handshake failure, or a generic “can’t establish a secure connection” — with no page at all.

Cause: HTTPS is fail-closed. If the requested hostname matches no published application, the edge closes the encrypted connection without completing the TLS handshake. Because TLS is never terminated for an unknown hostname, there is no opportunity to serve a branded page — the client only sees a transport-level failure.

This is expected and secure: an unrecognised HTTPS hostname reveals nothing. To diagnose it, open the same hostname over plain http://, where the edge can serve a page — you will get either the 404 or the 503 above, which tells you whether the hostname is unknown or suspended.

It works for some people but not others

Section titled “It works for some people but not others”

Symptom: The application loads from one network but hangs or is refused from another. Nothing appears in your workload logs for the failing client.

Cause: An IP allow/deny rule is filtering by source address. These come from the ipRules policy on your access entry, and they are enforced at the gateway — before TLS, before your workload — so a filtered client never shows up in your logs at all:

  • allow — when set, only the listed CIDRs or addresses may connect. Everyone else is dropped (default-deny). An absent allow list means “allow everyone.”
  • deny — the listed CIDRs or addresses are dropped, even if they also appear in the allow list. Deny always beats allow.

A dropped connection is silent to the client — it sees a timeout or a reset, and nothing reaches your workload. It is not invisible to you: the webapp application view’s Access → Recent denials now attributes these gateway ipRules denials to the app, so you can confirm a request was refused at the edge (and by which rule) even though it never hit your logs. Denials that can’t be tied to a specific app — requests to an unknown hostname, and per-source connection-rate limits — are deliberately not listed there, since they don’t belong to any one application.

Check your own source IP. The gateway matches on the public address the connection arrives from, which is often not the address shown on the client machine (NAT, VPN, and mobile networks all rewrite it). From the failing network, ask a public reflector what address you present:

Terminal window
curl -s https://api.ipify.org      # your public IPv4
curl -s https://api64.ipify.org    # your public IPv6, if you have one

Then compare that address against the rules on the access entry. Both lists accept bare IPv4/IPv6 addresses and CIDR ranges; remember a deny entry overrides an allow entry for the same address.

access:
  - name: api
    type: https
    hostname: { custom: api.example.com }
    policies:
      ipRules:
        allow: ["203.0.113.0/24"]   # only this network may connect
        deny:  ["203.0.113.7"]      # ...except this one address

If the address you present is outside every allow CIDR, add it (or its network) to allow. If it is caught by a deny entry, that entry wins regardless of allow — remove or narrow it. Re-apply the application for the change to reach the gateway.

Connections drop when traffic spikes

Section titled “Connections drop when traffic spikes”

Symptom: Under rapid reconnects or a burst of clients from one source, new connections start getting reset while steady traffic is fine.

Cause: The edge applies abuse protection per source address — a ceiling on connection rate and concurrent connections from any single IP. This shields every application on the edge from a noisy or hostile source; it is automatic and not something you configure per application. Legitimate clients rarely hit it; aggressive retry loops and load generators do.

Check: If a real client is tripping the limit, spread its connections or reuse them (keep-alive) rather than opening a new connection per request.

Still stuck?

Section titled “Still stuck?”

Work down this list — it separates a gateway denial from a request that never arrives:

  1. Reproduce over plain http://. A 404 means the hostname is unknown; a 503 means it is suspended; a redirect to https:// means the hostname is known and active (so the problem is further along).
  2. Confirm the hostname resolves. dig +short your-host (or nslookup) should return an Edgible edge address. No answer, or the wrong answer, means DNS — not the gateway.
  3. Check your source IP against ipRules using the curl reflector above, if the failure is network-specific.
  4. Rule out abuse protection if the failure only appears under bursty reconnects (see the previous section).

If the hostname resolves, http:// returns a redirect (not a 404 or 503), your source IP is within the rules, and you are not flooding connections, then the request is most likely not reaching the gateway at all — look at the client’s own network path and any corporate proxy before anything else.

Section titled “Related”