Introduction

An origin connection refused error means the request reached the server network path, but nothing accepted the connection on the target port, or the service actively rejected it. That is different from a timeout. The network path may exist, but the backend listener, firewall policy, or proxy target is wrong. The fix is to confirm the service is actually reachable on the expected address and port.

Symptoms

  • Reverse proxies or CDNs report connection refused from the origin
  • Public requests fail immediately instead of hanging for a long timeout
  • The issue starts after service restarts, deploys, firewall changes, or port changes
  • The server is online, but the application endpoint cannot be reached
  • Some ports or hostnames work while the main application path does not

Common Causes

  • The backend service is stopped, crashed, or failed to bind to the expected port
  • The application listens only on localhost while the proxy expects a different interface
  • Firewall or security group rules block the connection path between proxy and origin
  • Reverse proxy config points to the wrong host, IP, or port
  • Container or process networking changed and the old target is no longer valid

Step-by-Step Fix

  1. Identify which proxy or edge layer reports the refusal and which exact origin host and port it tries to contact.
  2. Confirm the backend process is running and listening on the expected socket instead of assuming the service start command succeeded.
  3. Check whether the app binds to the correct interface, because a service listening only on 127.0.0.1 can fail when another host must reach it.
  4. Review reverse proxy, load balancer, or CDN origin settings to verify the target address and port still match the live backend.
  5. Inspect host firewall, cloud security group, container network policy, or local packet filter rules for blocks on the required port.
  6. If the issue began after a deploy or restart, inspect service logs for startup failures, crash loops, or config errors that prevent the listener from opening.
  7. Retest from the proxy host or the nearest reachable layer so you can separate app failure from wider network failure.
  8. Put the correct backend target back in service only after it can accept direct connections reliably.
  9. Add monitoring on listener availability and service restarts so future refusals are detected before they become a full outage.