See why a request failed

A request that does not complete still appears in the traffic list, with the reason in one sentence. When the server cannot be reached, ReqRes answers the app with a 502 that names the reason.

The three outcomes#

The glyph takes the place of the status code. Hover it to read the outcome and the reason.

ReqRes closes a connection only when nothing has moved in either direction for 30 s between requests, 300 s while a response is awaited or streaming, or 10 minutes on a relayed connection. A download or stream that keeps moving is never cut.

Read the reason#

Select the row. A banner above the detail gives the outcome and the reason, for example "Failed. Could not resolve api.example.com — the name does not exist or DNS did not answer." The reason names the host, the port or the TLS alert when ReqRes knows them.

Below the banner, the inspector shows whatever the request recorded. An Aborted or Timed out row can have a status code and part of a body.

When the app refused ReqRes's certificate before it sent a request, there is nothing else to show. The detail lists the host, the app and the time, and says: "The app refused or dropped ReqRes's TLS connection before sending any request, so there is no request or response to show — and nothing reached the server."

What ReqRes answers the app#

When a server cannot be reached or fails before it answers, or when ReqRes refuses to send a request on, ReqRes answers the app itself with 502 Bad Gateway. The body of that response is the same one-sentence reason. A native gRPC call that ReqRes already sent on gets its own protocol's answer instead: HTTP 200 with grpc-status 14 (UNAVAILABLE) and the reason as grpc-message, for example when the server resets the call before it answers. When ReqRes cannot reach the server at all, a native gRPC client gets no answer: ReqRes can only offer it HTTP/1.1, so the client closes the connection. The row then says "ReqRes could not reach the server to agree on HTTP/2". A gRPC-Web or Connect call gets the 502.

Whether the server saw the request depends on where it failed:

• The name did not resolve, or the connection could not be made. The banner says: "The server never saw the request."
• The server hung up, or its TLS failed after the request went up. The request may have run. Check before you send a POST or DELETE again.
• ReqRes refused to send the request on, because it could not go out as the app sent it, such as a TRACE request that carries a body. The reason starts "ReqRes refused to forward the request". The server never saw the request.

When the app refuses ReqRes's certificate#

An app that pins its own certificate refuses ReqRes's, and so does a tool that does not trust the ReqRes CA. The request is one Failed row. ReqRes writes one such row for each host and app in 30 s, however often the app retries.

ReqRes then remembers the app and the domain, and passes that app's later connections there through untouched. They appear as rows marked "SSL pinned by" and the app's name, so trying again in the app works. An alert from the app counts at once. A bare hang-up counts only when it repeats within 30 s. The banner says what ReqRes remembered, with a Forget button to try decrypting again. Keep SSL-pinned apps working explains the list.

The banner can also offer an action:

• For a command-line tool, Export the CA and the environment lines… opens Settings ▸ Capture. A tool usually reads its trusted certificates from a file. When the banner also says ReqRes remembered the tool, click Forget once the tool trusts the CA, or its connections to that domain keep passing through without being decrypted. See Capture command-line tools and agents.
• When ReqRes has not remembered the app, Exclude host… stops recording the host after you confirm "Stop recording host?". The app then reaches the real server while capture runs. See Pass a host through untouched.

Show cancelled requests#

Browsers cancel requests constantly: a page navigated away, a tab closed, a spare connection dropped. ReqRes hides the Aborted rows of requests an app cancelled itself by default.

To show them, turn on Settings ▸ Capture ▸ Requests that did not complete ▸ Show cancelled requests.

While they are hidden, they are left out of the sidebar counts and out of every search, including outcome:aborted. An agent can still list them.

Find these rows#

Type an outcome: token in the search field:

A Failed row that ReqRes answered with a 502 also matches status:502 and status:5xx. A row that failed before it had a status, such as a refused certificate, matches no status: token. See Search and filter traffic.

How these rows count#

• Opening a Failed row never uses a free HTTPS inspection. An Aborted or Timed out row that kept a body counts like any other HTTPS request.
• A request that failed before it connected to any server went nowhere. The Destinations window leaves it out. See See where requests go.

What an agent reads#

• list_sessions marks these rows outcome=failed, aborted or timed_out, with the phase: dns, connect, tlsUpstream, tlsClient, request or response. A request the app cancelled adds cancelled_by_app. It filters by outcome.
• get_session gives an Outcome line with the phase and the reason.
• wait_for_session and wait_for_sessions skip these requests unless include_failed is true or outcome names one.
• diagnose_setup lists the apps that refused ReqRes's certificate.

Related#

• Read the traffic list
• Keep SSL-pinned apps working
• Pass a host through untouched