The first wall answers 429, and it is not about your IP

Plain HTTP clients get this back:

HTTP 429
Vercel Security Checkpoint (Code 11)

My first instinct was the usual one: change IP. So I tested it. A German datacenter IP. A residential US IP. A residential Russian IP. Same response, same body, three out of three.

That result is the useful part. When three networks with completely different reputations get the identical rejection, the network is not the variable. The client is. The checkpoint reads the JS and TLS fingerprint before it ever looks at where you are dialing from.

I also tried a real Google Chrome driven over CDP with Playwright. Same 429. So the fix was not "use a real browser", it was "use a browser that does not advertise itself". I moved the whole flow into Camoufox, a patched Firefox with a normal-looking fingerprint. The checkpoint cleared in four to five seconds and the login modal rendered.

What I took from this: when a wall answers identically across three unrelated networks, stop buying proxies and go fix your fingerprint. A proxy is the most expensive way to learn that your problem was never the IP.

The second wall is a Turnstile widget inside a closed shadow DOM

Behind the checkpoint sits the login modal, and it has a Cloudflare Turnstile checkbox: "Verify you are human".

It is not in the DOM the way you would expect. document.querySelectorAll('iframe') returns an empty list. window.turnstile is undefined. There is no [data-sitekey] node to grab. The widget renders inside a closed shadow root, so you cannot click it by selector and you cannot call its API.

What does work is coordinates. The only stable handle is the hidden input[name="cf-turnstile-response"] that eventually receives the token. Walk two to six levels up from that element with parentElement until you find a box wider than 200px with a height between 50 and 120, then click at x + 28, y + height / 2 with real mouse input. That is the checkbox. A synthetic element.click() does nothing here.

A couple of details that cost me time.

First, the click has to go through the real input pipeline. I ended up with humanized mouse movement rather than synthetic events, because events alone did not satisfy whatever the widget was checking.

Second, when the click lands, the token appears in the hidden input. Mine came back 666 characters long. If that field is empty, the "Send magic link" button will happily let you press it and quietly send nothing. Check the token, not the button state.

The paid fallback, and why it stays a fallback

There is a paid path: send the page URL and the Turnstile sitekey (0x4AAAAAADSW3gkuRirwHGjW) to a solving service. I used RuCaptcha's TurnstileTaskProxyless task, roughly 99 rubles per thousand solves, and wired the returned token into the response field.

It works, but be clear about what you are buying. You are buying a token, not a session. Everything downstream still has to look like a browser, and on this page the free path (one honest click) was faster and cheaper than the paid one. I keep the solver for the days the click stops landing.

Two things that broke after the wall

The magic link is a one-time token, and I burned one by opening a link from an earlier send. If you take the cutoff timestamp after you press the button instead of before, an old email sails through your filter and you land on error=CredentialsSignin with a token that was already spent. Take the timestamp first, then click.

Then the rate limit. I got four emails in eleven minutes and nothing for the next four. The button kept working and the mail simply stopped. Waiting it out was the correct move. Pressing it harder only deepens the hole.

And one thing that is not a bug at all: after login, this platform will not let you write until you create a publication. There is no editor for an account with zero publications. The signup flow ends on an empty state telling you to create your first one, which is easy to misread as a permissions problem. It is not. Create the publication, and the Write button appears.

What I would do first next time

Send the same request from three unrelated networks before touching anything else. If the answers match, the problem is the client, not the exit node. Then check whether the challenge widget lives in a closed shadow root before writing selectors for it, because there will be no selectors. And before pressing any submit button on a protected form, read the hidden token field that button is supposed to fill. That field is the real state machine, and the button is decoration.