> For the complete documentation index, see [llms.txt](https://docs.apexsolutions.lol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.apexsolutions.lol/start-here/requirements.md).

# Core Requirements

The five rules every solve depends on. Get them right once, and every solver guide assumes you already have.

Before any payload matters, your own client has to look like a real browser. These five rules are the floor for every solve in these docs — break one and the payload will not save you. Plain HTTP clients (requests, axios, net/http, fetch) trip all of them out of the box: their TLS handshake is not a browser's, and they reorder headers as they please.

Every solver guide here assumes you already meet these. Getting them right once saves you from chasing blocks that were never the payload's fault.

### 1. Browser-grade TLS client

Your client needs to open a connection the way Chrome does. tls-client and azuretls-client both emulate a real Chrome handshake, and anything else with a Chrome TLS profile works too. Set it up with:

* The **newest Chrome profile** your client ships (one version back is fine — Chrome's TLS ClientHello barely changes between releases).
* HTTP/3 turned off — most proxies still don't support it.
* Random TLS extension order enabled.

### 2. Exact browser header order

The order in which headers leave the client is itself a fingerprint — including the HTTP/2 pseudo-headers, which Chrome sends as `:method, :authority, :scheme, :path`. DevTools re-sorts headers, so it is the worst place to copy them from. Log the actual bytes with a proxy that keeps the wire order.

### 3. Session consistency

A session is a single identity: one User-Agent, one TLS fingerprint, one IP, one header order — and a cookie jar that actually keeps what the target sets. The client-hint headers (`sec-ch-ua`, `sec-ch-ua-platform`) count too. Change anything mid-flow and you are handing the site a reason to flag you.

### 4. Sticky proxies, never rotating

The proxy you hand to the solve has to be the same one your client uses against the target. A rotating proxy hands out a fresh IP per connection, so the solve runs on one address while the site sees another — blocked. Sticky or session proxies keep a single IP for the whole flow.

Confirm the address your proxy is presenting with `https://ip.apexsolutions.lol/ip`, called through that same proxy. Read it through the proxy: `/ip` answers with the outbound IP of whatever carried the request, not the address Forter or Cloudflare saw while solving (the solve reaches them through your proxy on its own). Treat it as a stickiness check, not a solve input.

### 5. Matched Chrome versions

Every solve is built around the exact User-Agent you send in `user_agent`, and the response tells you which one was used. That version has to line up everywhere your client says it: the User-Agent line, `sec-ch-ua`, and `sec-ch-ua-platform`. Bump them all at the same time when you upgrade Chrome — a version mismatch is a classic automation tell.

{% hint style="info" %}
**Chrome on Windows only.** Missing or non-Chrome-Windows `user_agent` (Edge, macOS, Linux, or a malformed string) — a clear 400, on purpose: we would rather reject it than silently build a payload for a browser you do not run.
{% endhint %}

### Still blocked?

{% hint style="info" %}
**Check the request, not the payload.** When the five rules above look right and the site still blocks you, the problem is almost always how the request itself went out. Capture the raw traffic with a proxy that preserves wire order and compare your TLS fingerprint, header order, User-Agent, and IP against these rules.
{% endhint %}