Understanding HTTP Responses and Network Timeouts

Overview

When a request travels from a visitor to your application through the WAF, there are multiple points where something can go wrong. Understanding where in the chain a failure occurred is the key to resolving it. There are three categories of responses you will encounter, each pointing to a different part of the request path.

Request Flow

1. Application Responses (200, 404, 500, etc.)

These responses come from your Heroku application. The request successfully passed through the client’s network, through the WAF edge, and reached your origin server. Your application processed the request and returned a response.

Common examples:

What this tells you: The entire request path is working. Any issues at this level are in your application code, not the WAF or the network. Debug these the same way you would without a WAF — check your Heroku logs, application error tracking, etc.

2. WAF Block (403)

A 403 response with a WAF block page means the request reached the WAF edge network and was rejected because it matched a security rule.

How to identify a WAF block:

• The response is an HTTP 403
• The response body shows a WAF block page with an incident ID and a block reason (e.g., “Cross-Site Scripting”, “SQL Injection”, “Blacklisted IP”)
• The blocked request appears in your WAF logs with details about which rule was triggered

Important: A 403 from the WAF looks different from a 403 from your application. If you see your application’s own error page (not the WAF block page), the WAF allowed the request through and your application rejected it.

What to do: Check the block reason and WAF logs. If the request is legitimate, you can resolve it by adding the IP to your allowlist or allowlisting the URL path. See Troubleshooting 403 WAF Blocks for detailed steps.

3. 502 Error (WAF Cannot Reach Origin)

A 502 (Bad Gateway) error means the request reached the WAF edge network, passed all security checks, but the WAF could not get a response from your Heroku application.

Common causes:

• Your Heroku dynos are crashed or not running
• Your application is taking too long to respond (Heroku’s 30-second request timeout)
• A recent deploy introduced a boot failure
• Your Heroku app is out of memory

How to diagnose: Visit your app directly at its .herokuapp.com URL. If you see errors there too, the problem is your Heroku application, not the WAF. Check heroku ps and heroku logs --tail for details.

See Troubleshooting 502 and 504 Errors for more detailed steps.

4. Connection Timeouts (No Response At All)

This is the most common issue that gets mistaken for a WAF block. The client’s connection times out before the request ever reaches the WAF edge network. You see a browser error like ERR_CONNECTION_TIMED_OUT or a client-side timeout error — not an HTTP status code.

This is not a WAF block. The WAF never received the request.

Why this happens

The problem is between the client and the WAF edge network — typically a routing issue at the client’s ISP or local network. Internet traffic passes through many network hops between a client and the WAF edge. If any hop along that route has congestion, packet loss, or a misconfiguration, the connection will time out.

How to identify a connection timeout

• No HTTP status code — The browser or client shows a connection error, not a WAF block page
• No entry in WAF logs — Since the request never reached the WAF, there is nothing logged
• Adding the IP to the allowlist does not help — The allowlist only applies to requests that reach the WAF. If the request never arrives, the allowlist has no effect
• Affects one location but not others — Other users in different locations or on different networks can access the site normally
• Often intermittent — The issue may come and go as ISP routing changes

What you can do

1. Test from a different network — Try accessing the site from a mobile phone on cellular data (not WiFi). If it works on cellular, the issue is your local network or ISP.

2. Test from a different location — Have someone in another office or city try. If it works for them, the problem is localized to your network path.

3. Run a traceroute — This shows every network hop between your machine and the WAF edge. Look for hops that time out or show very high latency. traceroute your-domain.com (Windows: tracert your-domain.com)

4. Contact your ISP — If the traceroute shows the failure is within your ISP’s network, they are the ones who need to resolve it. Share the traceroute output with them.

Unfortunately, there is very little we can do to resolve connection timeout issues on our end. The requests never reach our network, so there is nothing for us to unblock, allowlist, or configure differently. The resolution has to come from the client’s side — their local network, firewall, VPN, or ISP.

Quick Reference

Need Help?

If you are experiencing issues and cannot determine the cause:

• Contact us at support@expeditedsecurity.com
• Book a Call at https://app.harmonizely.com/expedited/30-min