requests.Session(): captcha POST returns 403 and next request still resolves to captcha

requests.Session() is probably not the problem here. A Session does persist cookies across requests, and per-request parameters override session values without being persisted back, so the basic GET-in-session then POST-in-same-session flow is valid.

Tthe first thing to inspect is the POST itself, not the follow-up GET. The 403, Server: ddos-guard, and {"hhcaptcha":{"isBot":true... response mean the submit is being rejected before the normal application flow accepts the captcha. In that case, the captcha state is never credited to the session, so the next request still lands on captcha.

Also, your fallback is wrong: if the form says method=POST, retrying the same payload with GET is not equivalent. Remove that path entirely.

A few things I’d check first:

• Don’t set the Cookie header yourself. Let requests.Session() manage cookies. That’s exactly what the session jar is for, and manually replaying cookies can easily put you out of sync.

• Make sure xsrf and any other hidden inputs are fresh from the current captcha page. If the page regenerates them and you submit an older value, the POST can fail even if the captcha text is correct.

• Compare your POST to the browser submit as closely as possible:

  • same hidden fields

  • same form encoding

  • whether the browser is doing a plain form submit or sending it via JS/XHR

  • whether any extra cookies appear between loading the page and submitting the form

• Your Accept header looks suspicious:

  text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
  

  That last part is probably meant to be:

  */*;q=0.8
  

  It may not be the main issue, but it’s worth fixing.

• If you’re manually preparing requests anywhere, use Session.preparerequest(), not Request.prepare(). Otherwise the session state (especially cookies) may not get applied the way you expect.

Something you might want to try is to use curlcffi instead of requests. This is a requests-compatible library that can mimic the TLS fingerprint of popular browsers, which many sophisticated application firewalls use to identify bot traffic even when the contents of the HTTP request are identical.

Obviously, you should also make sure your POST headers and content match a real browser as closely as possible, as any discrepancy can be used to reject your request as bot traffic.