SSL enabled causes infinite 301.

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-6.0

look at middle of Post
"
When it isn't possible to add forwarded headers and all requests are secure
In some cases, it might not be possible to add forwarded headers to the requests proxied to the app. If the proxy is enforcing that all public external requests are HTTPS, the scheme can be manually set before using any type of middleware "

Add a custom middleware to set the scheme to https

app.Use((context, next) =>
{
    context.Request.Scheme = "https";
    return next(context);
});

ximenchuifeng03 wrote:

ignore above code , ....

your problem is just   nginx is ssl ,but  your store of nopCommerce is not enable SSL  at the  Store Setting of  Admin dashboard

1. Update appsettings.json set UseProxy = "true"

"HostingConfig": {
    "UseProxy": true,
    "ForwardedProtoHeaderName": null,
    "ForwardedForHeaderName": null,
    "KnownProxies": null
  }

2. Enable ssl on store.
3. Stop kestrel service and start again.
4. Clear cache Memory cache or Redis Cache.
I have same issues, i think something in cache is store old value.

dinhvanvo1987 wrote:

Helped me to overcome http thumbs and icons requests.  They all secure (https) now. I had mixed http/https requests when used Nginx redirection with SSL disabled in NopCommerce.

Steps:
1. Disabled redirection in nginx config. Nginx listens both 80 and 443 and proxies requests to localhost:5000 (dotnet)
2. Enabled SSL in NopCommerce. It performs redirection 80 to 443.
(3. Restarted Nginx and NopCommerce services)

https://github.com/nopSolutions/nopCommerce/issues/6238

Looks like they will not fix that.
The problem is that null and empty string for "ForwardedProtoHeaderName" are not the same values and it does matter. In case of reverse proxy with ssl it needs to be set up with null or x-forwarded-proto.

titolr10 wrote:

According to 4.53 source code, setting "UseProxy" to "true" resolves the problem with reverse proxies for the most of cases even if the other Hosting Options remain default.

I still a bit confused why dotnet doesn't listen to 5001 for https. But it is not important.