Cloudflare Error 1010: Access Denied by Browser Signature

What the error means

According to the Cloudflare documentation, error 1010 means access to the site is denied based on your browser's signature. The cause is a decision by the site owner, who blocks requests by client type.

Some of these refusals come from the Browser Integrity Check: it filters out clients whose User-Agent looks like a program rather than a browser. As an example, Cloudflare cites the default User-Agent of the urllib library in Python.

A proxy does not affect 1010: it changes the address the request comes from, but not how your program identifies itself or which headers it sends.

Causes

• The program sends the library's default User-Agent. The site sees that the request does not come from a browser.
• The User-Agent is empty or does not match the other headers. For example, there is a browser name, but the headers usual for that browser are missing.
• The site owner has banned certain browsers or programs. Such a rule applies regardless of the address.
• Browser extensions or settings change the headers. Spoofing the User-Agent in an extension makes the request atypical.

How to fix it

1. Open the site in a regular browser without extensions that change headers.
2. If you are writing your own program, do what Cloudflare recommends: send a descriptive User-Agent that names your application.
3. Check that the program sends a normal set of headers and accepts cookies. The glossary explains what a User-Agent is.
4. If you need access for work, write to the site owner and include the Ray ID from the error text: only the owner can turn off the check.
5. Do not fake client data to pass the check: the acceptable use policy forbids getting around restrictions a site has imposed.

How to check that it works

Open the same site through the same proxy in a regular browser. If the page opens in the browser but the program gets 1010, the issue is in how the program presents itself.

Two-minute diagnosis

First paste the line into the proxy checker. If the proxy works there, the cause is in your app or its settings. If not, test the line from a terminal:

curl -v -x "http://USERNAME:PASSWORD@gw.prokso.com:823" https://api.ipify.org

• A < HTTP/1.1 407 line right after CONNECT means the proxy answered. The name after the code, for example NO_USER, points to the cause.
• The proxy answered CONNECT with 200 and then another code arrived - the proxy works, and that answer came from the website.
• No answer at all, only a timeout - the connection never reached the proxy: check the host, port and network.