The header for headed Chrome is mostly the same minus the “Headless”. The following script uses to get a JSON response that represents the request the server received.

We can use a service that echos back our HTTP requests to inspect the differences between a request made from headless and headed Chrome. This points us to the content of the request alone. Comparing HTTP Request headersīecause there is (supposed to be) little difference between Chrome when run in headless vs headed mode it’s a reasonable assumption that the core network stack is the same and there are no differences in how the browser transmits requests at the packet level. The request itself is a bunch of bits and bytes sent over the internet and accepted by a server. That rules out troubleshooting anything after the page render and limits our scope to the request alone. This means that a server somewhere made a call based strictly on what we sent for that first request and our block has nothing to do with page content. The original page wasn’t rendered and the browser made no other requests. What do we know? We know that the browser made a single request and we received a response that already said access denied.

Troubleshooting is sometimes seen as running through a checklist but that only works if you have encountered the problem before. This may sound basic but, unless you understand why, it’s non-intuitive how to get there. Without this step it’s impossible to pursue a course of action that targets the unknown and isn’t redundant. When troubleshooting it’s important to identify what we know and what we don’t know. This doesn’t happen at all in headed mode. The initial response is an “Access Denied” page and that’s all we can get when running Chrome in headless mode.

In this example the server didn’t even respond with the proper web page itself. An example of a page blocking headless Chrome

Megasync access denied