I cannot think of any reason why Netlify would return a 403 for an otherwise valid HTTP request. I’ve seen issues which might generate a 404 but never a 403. Also, if we serve a 403, there is a record of the 403 in the request logs. I see no 403 requests for this site during the times mentioned.
If there is no proxy, Netlify can see all steps in serving the content and you can see all the information at the browser/request end. We have logs for the entire process and can troubleshoot it in detail.
When a proxy is introduced, now there is a hidden layer between our systems and the browsers or other software making the HTTP requests. There is a layer we cannot troubleshoot without data from the proxy.
What often occurs is this:
- Netlify says we sent the data correctly and the proxy is at fault.
- The proxy says they are sending the data correctly and Netlify is at fault.
If the proxy service can provide the
x-nf-request-id headers for the 403s, we can troubleshoot the issue in more detail. Again, though, I see no 403s at the reported time for that site.
If the 403s were from Netlify, those responses will have an
x-nf-request-id header. That header would help us to find the specific HTTP request/response which generated the 403 and we could find out why it occurred.
If we don’t have the
x-nf-request-id header, then we will need additional details to research. For example:
- the date/time/timezone for the HTTP request
- the URL requested
- the IP address making the request
- the IP address that responded
Finally, if we cannot get troubleshooting details from the proxy, the only remaining option is to remove the proxy. If the issue stops when the proxy is removed, then this becomes evidence to support the hypothesis that the it is the source of the issue.
To summarize, with no proxy we can troubleshoot the request from end to end. With a proxy, however, we now need information from the proxy to troubleshoot and, without it, the only option left is to remove the proxy itself for testing.