> ## Documentation Index > Fetch the complete documentation index at: https://docs.roolink.io/llms.txt > Use this file to discover all available pages before exploring further. # Troubleshoot a block > A site checks your connection, then your headers, then your identity, then your IP, and only then the payload. Find the first check you failed. A protected site does not judge your request all at once. It looks at the connection first, then the headers, then whether everything describes one browser, then the IP, and last of all the payload Roolink built. A failure at any layer looks the same from the outside, a block page or a cookie that never flips, so the useful question is not "why am I blocked" but "which layer said no first". ## Start from the first failure Find the earliest request in the flow that did not behave the way it did in Chrome. Not the last one, and not the one that carried the payload. The layers are checked in order, and a failure early on makes every later request fail too, so the last failure tells you almost nothing. Record the run in [powhttp](/capture-requests) if you have not. It shows every request your client made, with status codes, and puts Chrome's recording of the same flow beside it. ## Match the symptom | What you see | Why | Fix | | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | Connection reset, TLS error, or a block on the very first page load with no cookies set | **Connection.** The handshake was not Chrome's. An ordinary HTTP library, or a TLS client with a non-Chrome profile. | Build the client on the [Set up your HTTP client](/http-client) page and compare its handshake with Chrome's in powhttp. | | Block on the first page load, cookies were set | **Headers or IP.** Headers missing, extra, or out of order; or a datacenter or flagged IP. | Compare the page request with Chrome's header for header. `sec-fetch-*` and `priority` are the usual gaps. Then check the IP is residential. | | Page loads, the protection script request is refused | **Headers.** Script requests carry their own header set: `sec-fetch-dest: script`, a `referer`, no `upgrade-insecure-requests`. | Copy the script request's headers from the recording, not the page's. | | Sensor posts answer `200` or `201` but the cookie never flips after three posts | **Identity.** The payload describes one browser and the request another. Different User-Agent to the site and to Roolink, or `sec-ch-ua` disagreeing with the User-Agent. | Send one User-Agent everywhere and copy the client hints from the same Chrome. [Supported browsers](/supported-browsers). | | Roolink answers `422` `no device profile for user agent` | **Identity.** The User-Agent is not one Roolink has a profile for. | Use a User-Agent Roolink has a profile for; current desktop Chrome is the safe choice. [Supported browsers](/supported-browsers). | | Everything works, then a block partway through the session | **IP or cookies.** The proxy rotated, or a cookie the site set was dropped. | Use a sticky proxy session for the whole flow and one cookie jar that keeps every cookie. | | Works one day, blocked the next with no code change | **Freshness.** A script path, cookie name or parsed script result was hardcoded and the site rotated it. | Read the script path from each page response and re-parse the script when it changes. | | `428` on the protected request | **Sec-CPT.** The site added a second challenge on top of the sensor. | Follow [Sec-CPT](/akamai-web/sec-cpt). | | `429` with an `sbsd` cookie or script | **SBSD.** The site added its own challenge. | Follow [SBSD challenge (429)](/akamai-web/sbsd-429). | | Sensor posts accepted, protected request still blocked, cookie shows `~0~` | **Payload or IP.** Rare. Either the site scores the IP badly or a second protection layer is in front of the endpoint. | Change proxy session and retry once. If it persists, bring it to Discord. | Some sites never flip the cookie to `~0~` and still serve the protected request after three posts. Make the request before concluding you are blocked. ## Prove it with a comparison run Point your client at powhttp instead of your proxy for one run, walk the same flow you recorded in Chrome, and read the two recordings request by request. Your client's requests should differ from Chrome's only in cookies and the values that legitimately change per site. The first request where that is not true is the one to fix. ```bash theme={null} export PROXY_URL="http://127.0.0.1:8080" # the address shown in powhttp's window ``` While the client runs through powhttp the site sees your own IP, so use the run to compare requests, not to judge whether the site blocks you. ## Ask in Discord If the recordings match and the block persists, bring these to [Discord](https://discord.gg/rooapi): * The request and response headers of the first blocked request, from powhttp. * The User-Agent you send, the TLS client and profile you use, and the proxy type. * The site and the page you start from. With those in hand a block is usually diagnosed in one reply. Without them, the first reply is a request for them.