You're right, and sharper than the post was. I framed it mostly as JA3 and header order, and the HTTP/2 SETTINGS frame ordering is the part people miss most — it's the one that survives a correct JA3 and still 403s, which is exactly what makes it so miserable to debug. Hard to conclude "my token is fine" when the thing rejecting you never looked at the token. The dynamic sitekey point is a good addition too. Intercepting the /cdn-cgi/ calls is the reliable way to get them; reading the DOM works right up until the SPA mounts the widget late and you quietly grab a stale one. One thing I'd add from your side of the stack: session stability matters as much as fingerprint stability. A clearance earned behind one exit and replayed behind another fails identically to a bad token — same 403, and nothing in the response tells you which it was. So a rotating-per-request pool breaks Turnstile flows even when everything you listed is correct, and the failure looks like a solver problem to whoever is debugging it. Proxy choice and captcha handling aren't really separable problems, and I don't think either side of that market says so often enough. Appreciate the detail — genuinely useful.
