A browser reports too many redirects. Two competing rules may be responsible rather than a broken destination: one component enforces www, while another removes it. With a reverse proxy, the internally observed connection may also differ from the public HTTPS connection.
Use a public address on your own website and record every hop. A fictional pattern is:
https://example.invalid/ → https://www.example.invalid/
https://www.example.invalid/ → https://example.invalid/
The two destination values already reveal the loop. Clearing browser data does not correct those server rules.
Assign responsibility to each layer
Record which component normalises hostnames and which enforces HTTPS. Inspect the application, web server, CDN and reverse proxy for conflicting settings. Choose one intended public form and change the conflicting rule deliberately.
Proxy headers require a trust boundary. An application should use information about the original connection only from its intended, trusted proxy chain. Do not copy a blanket configuration that trusts every incoming forwarded header. The appropriate setting depends on the actual server and framework.
After changing the configuration, test supported HTTP and HTTPS entry points with and without www. They should reach the intended public address without looping. Include a subpage so that a homepage-only rule does not conceal remaining errors. Use a window without an authenticated session or previously cached redirects.