A refusal before the request arrives
A transport level block happens during or immediately after the TLS handshake. The connection is reset, an alert comes back, or the peer closes the socket without an application response. Your client raises a connection error and never sees a status code. That timing is the first useful fact, because it places the decision before any header or body value was available to the server.
An HTTP response means the opposite. The connection completed, the request arrived, and the application evaluated it. When a mobile API refuses a script that copies the app's headers exactly, the presence or absence of a status code answers the first question: whether the refusal came from the protocol layer or from the application.
What the server reads before your payload
A TLS client announces its capabilities at the start of the connection. The opening message carries the protocol versions the client supports, the cipher suites in the order it prefers them, the extensions it understands, and the signature algorithms it will accept. A client that speaks HTTP/2 also sends a preface that lists its settings and window sizes. None of those values come from your request code. They come from the library that implements TLS and HTTP on your machine.
Different stacks produce different announcements. A mobile HTTP client, a language runtime and a desktop browser each have a recognisable shape, and that shape stays stable for a given library version. A service can group clients by implementation before it accepts a byte of payload, and it can refuse the group it does not expect. The inputs used for that grouping are widely documented, which is why the technique appears in ordinary bot management as well as in mobile API protection.
What a transport block does not tell you
A handshake refusal says nothing about the request signature, because the server never received a request to validate. It says nothing about the account, the token or the session, because those are evaluated later in the flow. Building a theory about the signature at this point wastes the strongest evidence you have, which is the timing of the failure.
A refusal from the server also differs from a refusal produced by the app. Certificate pinning is enforced on the device by the application, which compares the certificate or public key it expects and aborts its own connection. That failure appears in the app's own logs and never reaches a backend decision, so pinning and a server side transport block are different problems with different fixes.
One caution belongs here. A reset during the handshake does not prove the block is deliberate or aimed at your script. Intermediaries, rate limiters and network policy devices close connections on the same inputs. The destination and the repeatability of the pattern decide which one you face.
The tests that locate the decision
Each test below changes one thing and watches whether the refusal follows it. Run them in order and stop when the response changes.
- Send the same client to a different host. If the connection succeeds elsewhere with the same request, the refusal tracks the destination service rather than your machine or your network.
- Repeat the request from a browser on the same machine. A browser and a script share an operating system but not a TLS implementation, so a browser that succeeds while the script fails points at the handshake.
- Switch the HTTP version where the library allows it. A client that succeeds over HTTP/1.1 and fails over HTTP/2 has a block at the newer layer, which is decided after the certificate exchange.
- Change one advertised property at a time. Where the library exposes accepted versions, the cipher list or the ALPN list, adjust one value and retest. Values that change the outcome are part of the check.
- Read the failure itself. A TLS alert with a specific description comes from the peer. A bare reset with no alert is consistent with a device in the path.
What changes the outcome
The available moves depend on how much of the handshake your client controls. Standard runtimes expose the protocol version range and, in some cases, the cipher list. Extension ordering, padding values and exact HTTP/2 settings are usually internal, so a normal library cannot be configured into a different identity.
Two routes remain. The first is to move the request onto a stack that already looks like the expected client, which often means running the call from a device that uses the same platform networking code as the app. The second is to use a TLS implementation that lets the handshake be described rather than inherited, which several maintained libraries now support. Both are engineering work on the transport, and neither changes the request content.
How this splits a project
Request reconstruction and transport identity are separate pieces of work. Recovering the endpoints, the signing scheme and the session flow produces a client that knows what to say. Getting that client past the handshake is a transport problem that has to be solved for the environment the service expects. Treating the two as one problem hides which of them is blocking you.
Send the failing connection together with the captured request. We identify whether the refusal is transport or application, reconstruct the request logic, and state plainly what environment the client has to run in. Certificate pinning and traffic analysis covers the client side checks that stop a capture on the device.
Related work
Reviewed 28 September 2026 · SReverse research desk