502 Bad Gatewayafter messing with host files


(OeilDeLance) #1

I was trying to set up a DNS link for my discourse forum following a tutorial that told me to modify the etc/hostname and etc/hosts files
After a few attempts the server is now showing "502 Bad gateway " even though I reverted those files to their initial state (and rebooted)

Are there any ways I could diagnose what is wrong ?

Address of the forum: http://51.15.243.192/


(Michael Brown) #6

A “502 Bad Gateway” response means that the server sending the response (in this case, nginx) is not getting a good response from the next step in the chain (in this case, the Discourse application) to send back to the client.

This could be caused by, e.g.:

  • Discourse is not running
  • it’s sending back garbage
  • nginx is pointing at the wrong spot

Check the nginx error logs for more details and ensure Discourse is actually running and listening where nginx expects to send requests.

It would also be helpful to show which tutorial you followed for the installation.

KeyCDN also has a good page explaining what is going on (even though you’re not using KeyCDN it’s applicable to you):


(OeilDeLance) #7

Thanks for you response, I followed that tutorial [Tuto] Associer un nom de domaine à un serveur - mondedie.fr
I didn’t link it because it is in french but it is basically telling me to modify the following files: etc/hostname and etc/hosts

I didn’t go any further than that

Could it be that I did not save them in the right format ?

I reverted them to their original state with SublimeText which is not the best way to go about it I agree.

I will look at the material you linked tomorrow and keep you updated. Thanks again !


(OeilDeLance) #8

Actually I have some developments:
The server pings all right

Also the error log says :

2018/05/28 22:30:36 [error] 3343#0: *79 connect() to unix:/var/www/discourse/tmp/sockets/thin.2.sock failed (111: Connection refused) while connecting to upstream, client: 5.51.116.205, server: enter.your.web.hostname.here, request: “GET / HTTP/1.1”, upstream: “http://unix:/var/www/discourse/tmp/sockets/thin.2.sock:/”, host: “51.15.243.192”

Strange this enter.your.web.hostname.here thing I don’t remember ever writing that and discourse was working before.


(Michael Brown) #9

Ce n’est pas une problème, nous avons deux personnes qui parlent français et habitent en France. And at least a couple others with some grade-school french such as myself :canada: (and probably other people in between)

Are you using our supported docker install?

Regardless, that ‘Connection refused’ means that it can’t connect to the socket to send the request to Discourse, so Discourse itself isn’t running.

That’s from out sample nginx config: discourse/nginx.sample.conf at master · discourse/discourse · GitHub

I strongly recommend following the officially supported docker installation method so that we can support you.


(OeilDeLance) #10

All right I could do that docker thing. But can I do a backup of my forum and restore it later in that state ? Something tells me it is not going to be that simple.

i think I am not using that docker install I am using a default setup by scaleway: a lowcost web host


(Kane York) #11

It is, though! :smiley:
Discourse has very good backup/restore. It sounds like you may have some problems taking the backup right now, though, if you can’t get to the web UI. It’s possible to do from a command line.


(OeilDeLance) #12

Sounds very good @riking I’ll do that.
This tutorial it assuming a docker install (my forum is not using docker) Backup discourse from the command line

So does that mean I have to locate the standalone.backup file and run it ?

Also @supermathie is it possible to run a backup from the command line on a non running and non docker discourse and restore it on a fresh docker install ?

Also worthy of note: I am running a really old version of discourse: 1.3.5


(Michael Brown) #13

Regardless of the version of Discourse, if you can’t get it back up and running you can preserve the data by:

  • make a copy of the VM (always do this so if you screw up badly you haven’t lost anything)
  • saving the configuration (app.yaml)
  • dumping the postgres database with pg_dump
  • tarballing all of the uploads and backups

Then if you restore the uploads/backups and database into a new installation and run migrations you should be good to go.


(OeilDeLance) #14

Would you have a reference tutorial for that ?
By VM you mean what I can access on my server via file Zilla right ?


(Michael Brown) #15

Without knowing the intricacies of your setup I can’t point to anything in particular that would be targeted at your specific needs.

If you require assistance with this I suggest posting in #marketplace.