chromedp VS CycleTLS

There are a billion things that you need to consider when building a decent web crawler, especially interacting with pages in the modern web. For example, a lot of content is dynamically loaded by the browser nowadays, and won't show up if you make a simple HTTP request. Open your browser devtools and look at the network tab after you make a request, and you'll see it makes loads of auxiliary requests. Some content is also only loaded after you interact with it (e.g. hover, click). For that reason I'd recommend using something like chromedp and do browser based crawling, even if it's much slower.

You could use something like the chrome dev tools (https://github.com/chromedp/chromedp) or look into JS runtimes in Go and try to handle the I/O yourself.

Thanks. I've found Chromedp [0] to be a good Selenium replacement when programming in Go. Used in conjunction with HeadlessShell [1] you can deploy a Go app into a container and do the testing all within the same container with low overhead.

[0] https://github.com/chromedp/chromedp

Is it node specific? Could you just use https://github.com/chromedp/chromedp and run it as an actually webpage and get the value from that?

It looks like https://github.com/chromedp/chromedp is the most popular option. There's also https://github.com/playwright-community/playwright-go. Any thoughts or advice about using these tools?

The alternative is to drive, for example, Chrome with the DevTools protocol (using something like https://github.com/chromedp/chromedp or https://github.com/raff/godet (this is my version of a DevTools driver).

A lot of websites nowadays add fingerprint checking. So even if you fake the headers - it wouldn't help, as cloudflare still knows you are making request from go / python / whatever. So there is a lib to spoof fingerptint - https://github.com/Danny-Dasilva/CycleTLS . It may work for you .

While it can still be spoofed using several packages , e.g. https://github.com/Danny-Dasilva/CycleTLS it can still provide a meaningful/easy-to-manipulate signal.

Moreover, most bots conducting L7 DDoS don't use real/headless browsers in order to be able to scale their attack, so it's highly likely they'll have a discriminating/inconsistent TLS fingerprint.

This can also be done directly in Fastly using e.g. https://developer.fastly.com/reference/vcl/variables/client-...

Another approach to proactively flag malicious IPs is to scrape free proxies. Indeed, most DDoS leverage lot of cheap/know bad IPs. It's frequent to see these free proxies in these attacks.