NGINX is Broken?

Rebuild did nothing, it’s still denying HTTPS and on top of that, I’m back to the NGINX welcome page on HTTP.

You definitely have nginx installed.

Have you tried
apt purge nginx

or

dpkg -l |grep nginx

?

Once you kill nginx, what does ./discourse-doctor say?

Returned, nginx not installed

Returned, Nothing

All of the inputs (Like Email, web address) are blank
And there’s 2 containers running on Ports: 80 → 80, 443 → 443, and 2222 → 22
It says the discourse container app is running
And it says the Discourse Version is NOT FOUND

Whoops, didn’t scroll down, let me read the output text and see what it says.
EDIT: It says the same thing

Did you start this show by running ./discourse-setup?

What are they?

You mean did I go through the setup process (which I did), or did I not run ./discourse-doctor which is what I ran.

My mistake, there was only one, it is 4efab95a60b8

Now the page on HTTP, just says it didn’t send any data, so now there’s not even an NGINX page.
EDIT: We’re back to the nginx page
EDIT2: Nevermind, we’re not.

What does docker ps show?

The exact same container as the text file.

Maybe a reverse proxy with caddy would be better in this scenario?

I was wanting the name of what it was. The is number is meaningless.

I’ve had success with caddy in the past. It’ll likely have the same problem, though.

Here’s a suggestion.

Go sign up for the $5 droplet at DigitalOcean. Follow the install guide to the letter, no copying of additional certificates or anything else.

DO droplets are prorated, if you follow the guide (which takes 30 minutes or less) the cost of proving the install is $0.02. If you don’t want the instance afterwards just hit the destroy button.

If it still fails then there’s something we can begin to troubleshoot.

If it works then it proves this isn’t a discourse issue. If you choose to use a more complicated environment you unfortunately also accept responsibility for the extra challenges it presents. The standard install has been proven on the Ubuntu image at DO and their Network policy doesn’t cause issues with Lets Encrypt (but does occasionally need moderate remediation to send email).

Note that if you’ve been requesting and re-requesting the same certificate name it’s possible that Let’s Encrypt has put that particular FQDN on cooldown.

6 Likes

Well I finally got it. Here’s what I did. I installed Caddy, and setup a proxy to redirect all connections from the URL to localhost:444, but that wasn’t it. I went into the app.yml and changed the Port to this

- "81:80" - HTTP moved to port 81 to reserve for Caddy
-"444:443" -Caddy Will Handle HTTPS

Then, when I go to the website, it’ll load in and not deny connection to HTTPS!
Thank you to everyone who helped and left suggestions!

I will definitely be doing this, if I have to install discourse again.

3 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.