Skip to main content
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 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

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.
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:
  • 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.