@hez2010 One more idea. By accessing directly, the only difference I can see between requests that succeed on the direct access and the ones that fail with the proxy are the absence of the Cookie request headers.
In my debug logs, the upstream replies with headers like
"Set-Cookie": ["XSRF-TOKEN=66f5a97c-8ac9-47cd-8115-b7d3c49ec64e; path=/; secure"]} but I do not see these cookies being set, perhaps because the browser sees that the client is on an HTTP page.
This is just a hunch, and doesn’t explain why some requests fail and others succeed.
Still, you might try this on an HTTPS page and see if it works.
(Edit: I’m now almost certain that is at least one problem, if not the problem. If you go to the Application tab of the web inspector, then go to Storage -> Cookies, you will see that no XSRF-TOKEN cookie is set on the proxied HTTP page – probably because it is a secure context cookie only – but it is set on the direct access HTTPS page.)
Dang. I hoped I had it. I cheated a bit and forced the cookie to set on HTTP pages by adding this to the reverse proxy config:
"search": "; secure",
It successfully manipulated the response header so that the cookie was set and is being included on the proxied requests, BUT… still getting 400s back.
What is your working proxy config for whatever you’re using now?