Attempting to add proxy host but keeps giving me "Internal Error" message

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I am having an error when using Nginx Proxy Manager, I am able to get my host on there but when I go to the 'SSL' tab to request a new SSL certificate, as well to force SSL and HTTP/2 Support I get the error message of "Internal Error". I will not allow me to encrypt. I am hosting this through docker.
I ran this command:

It produced this output:

This image is the error it gives.

when I check the log on this container this is what it outputs.

[1/4/2024] [8:51:27 PM] [Nginx ] › :information_source: info Reloading Nginx
[1/4/2024] [8:51:32 PM] [SSL ] › :information_source: info Requesting Let'sEncrypt certificates for Cert #24:
[1/4/2024] [8:51:32 PM] [SSL ] › :information_source: info Command: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-24" --agree-tos --authenticator webroot --email "" --preferred-challenges "dns,http" --domains ""
[1/4/2024] [8:51:47 PM] [Nginx ] › ⬤ debug Deleting file: /data/nginx/temp/letsencrypt_24.conf
[1/4/2024] [8:51:47 PM] [Nginx ] › :information_source: info Reloading Nginx
[1/4/2024] [8:51:47 PM] [Express ] › :warning: warning Command failed: certbot certonly --config "/etc/letsencrypt.ini" --work-dir "/tmp/letsencrypt-lib" --logs-dir "/tmp/letsencrypt-log" --cert-name "npm-24" --agree-tos --authenticator webroot --email "" --preferred-challenges "dns,http" --domains ""
Saving debug log to /tmp/letsencrypt-log/letsencrypt.log
Some challenges have failed.
Ask for help or search for solutions at See the logfile /tmp/letsencrypt-log/letsencrypt.log or re-run Certbot with -v for more details.

I also get this message when I try to run a dry run.
[root@docker-ea10064175fe:/app]# certbot renew --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log

No simulated renewals were attempted.

[root@docker-ea10064175fe:/app]# certbot renew --staging
Saving debug log to /var/log/letsencrypt/letsencrypt.log

No renewals were attempted.

[root@docker-ea10064175fe:/app]# certbot --version
certbot 2.5.0

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): I am using Nginx Proxy Manager GUI

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot version 2.5.0

NPM is difficult to debug because it hides the actual error message. We would have to see the log it names to know the actual error.

But, it might have something to do with not being able to reach your domain using HTTP. You are using the --webroot challenge with Certbot and that needs HTTP (port 80)


But it doesn't specify the webroot path.


NPM does something weird for that. I think its in the letsencrypt.ini but not sure. It shows up in the log if we ever see that.

Just another one of the frustrating things about NPM


One of [very] many!

1 Like

Okay, so I can reach my domain using nslookup and it is correct. I will look at the logs to see more information about it in a little while. I do have this running through a pfsense firewall, having port 80 and port 443 open through NAT. I am very new to having this implemented locally. I appreciate the help.

HTTP (port 80) requests to your domain name are still not reaching your system. If you are sure pfsense is correct then check the rest of the comms setup.

Sometimes residential ISP will block port 80 (and 443). You may need to check that they allow those inbound to your location (Spectrum?). If they are blocking, see if IPv6 is supported and whether they allow those ports with that. You may need to switch away from IPv4.

Click the Rerun Test link at top of that page to run another test after making changes. Or, just start fresh at


Yes, spectrum is my ISP.

1 Like

Now you know who to call and what to ask :slight_smile:


According to this page:
Blocked Ports | Spectrum Support
They don't [currently] block inbound HTTP [TCP port 80].

What other devices are there between your web server and the Internet [that could block HTTP]?


Saw a post on Spectrum community forum where they use CGNAT in at least some regions for IPv4. Would have same result as outright blocking.


In this case, the IP in DNS is routable:


If it had been CGNAT[ed], the IP would be from that net block [100.64/10].
That said, ARIN shows the IP as being from Charter Communications [not Spectrum]:
ARIN Whois/RDAP - American Registry for Internet Numbers

How did your :crystal_ball: see that Spectrum [of light]? - LOL

2 Likes 16336 IN PTR

But, wouldn't the 100.64/10 range only show in their router? I thought the reason it is tricky to know CGNAT is the DNS IP looks "normal" but just routes to the ISP and never reaches customer premises because of the CGNAT


I suppose that could be the case here.
We don't have much evidence either way.
A traceroute might be one simple, but very helpful, bit of info.


@BloodyAlt When you call them about this make sure you also ask if you are behind CGNAT. This would block inbound requests to you on those ports using IPv4 too.

If CGNAT is in effect you could ask for a fixed IP but that may require a business account.


So I called Spectrum, and they said that they were not blocking that port and that I was not behind a CGNAT. They said they aren't blocking any ports. I used Open Port Check Tool - Test Port Forwarding on Your Router to see if port 80 is closed and it is closed.

Further confirming with the Spectrum help desk, it is not anything on their end they can do but my spectrum router is actively blocking port 80, and I've been trying to look up ways to resolve it.

My pfsense firewall has WAN rule set up for TCP port 80.

Also, I looked into the most recent log file and this is what it consists of:

2024-01-06 03:14:44,520:DEBUG:certbot._internal.main:certbot version: 2.5.0
2024-01-06 03:14:44,520:DEBUG:certbot._internal.main:Location of certbot entry point: /usr/bin/certbot
2024-01-06 03:14:44,520:DEBUG:certbot._internal.main:Arguments: ['--non-interactive', '--quiet', '--config', '/etc/letsencrypt.ini', '--work-dir', '/tmp/letsencrypt-lib', '--logs-dir', '/tmp/letsencrypt-log', '--preferred-challenges', 'dns,http', '--disable-hook-validation']
2024-01-06 03:14:44,521:DEBUG:certbot._internal.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2024-01-06 03:14:44,539:DEBUG:certbot._internal.log:Root logging level set at 40
2024-01-06 03:14:44,540:DEBUG:certbot._internal.display.obj:Notifying user:

2024-01-06 03:14:44,540:DEBUG:certbot._internal.display.obj:Notifying user: No renewals were attempted.
2024-01-06 03:14:44,541:DEBUG:certbot._internal.display.obj:Notifying user: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
2024-01-06 03:14:44,541:DEBUG:certbot._internal.renewal:no renewal failures

1 Like

Yeah, you haven't gotten any certs so there is nothing to renew

How do you know it is the router? Can you access its admin panel?

Are you sure it is not something else ... perhaps your "docker" config?


Please provide more detail on that.
Where exactly do those HTTP requests go?


I see that there are not any to renew but that is the most recent log when I try to encrypt it. I am not 100% sure that it is the router, that is where my process of elimination has led me. The only way to access the Spectrum admin panel, for their equipment, is through the app. The only way to port forward it seems, on the app, is to select the specific device. I can not do that since I have it going through a switch.

I can check my docker config, but it seems like it should be working.

I have my pfsense firewall has a rule set up to allow HTTP requests on port 80 through.

Through to where?
To what internal IP?