Problem

This would appear to happen because you're not using canonical URLs, whereas your backend is enforcing such URLs through these 301 redirects, whereas it is not actually aware of the canonical address scheme.

Solution

• Best solution would be to fix your front-end code to always use canonical URLs. E.g., in the examples you provide, there's a difference in whether or not a trailing slash is present in your API endpoint.

• You should probably configure your back-end to be properly aware that it's being accessed through https, e.g., add something like the following next to all your other proto_set_header directives in your nginx that terminates https and passes the traffic to the backend:

  proto_set_header    X-Forwarded-Proto   $scheme;

Other thoughts

• Another solution would be to configure http://nginx.org/r/proxy_redirect to properly recognise the local Location headers returned by your backend, and convert them on-the-fly as needed; however, the prior two options are probably a better approach in your situation.

I am not entirely sure, because your screenshots are a bit conflicting, but here goes:

In your inspector screenshot we see one request to https (which is cancelled) and one to http (which is blocked due to mixed protocols). The hint is in the cancelled one, being cancelled means there was no redirect there, but that the browser decided it no longer needed the request. There are several previous questions that had similar issues, see here and here two examples.

One reason why a request gets canceled is if the button/input/link you use to change the date of your FullCalendar is not just doing an ajax request but also doing a second http request (because of a wrapping form, href, etc). You have not included your html and JavaScript of your FullCalendar implementation, so I do not know this for sure, but check that you do not have a form surrounding the input element, or if you wrote your own event handler do the following.

function(e){  e.preventdefault();   .... // your date switching code here   return false;}

If you use a link with an onclick attribute, make sure you add ...(yourcode);return false; at the end.

Important: If my theory is right, this means the line from your log doesn't actually correspond to the same thing we see in the inspector and is in fact a redirect from HTTP to HTTPS, not the other way around. This would be hard to see because nginx does not include the request protocol in the log by default.