I’m sorry to hear about the trouble this is causing for you today. I’d love to give you some direction on this, but also would like to set some expectation so that we’re working from the same page.
Our droplets are self-managed, which means that you manage the software on them. We will manage the infrastructure that keeps them online, but we never log in to your droplet. Because of this reality, it is important that you not wait for our support team to offer help for this. They can and will offer great advice, but that still leaves you in the driver’s seat to resolve this issue. In the case of a 502 error, you’re seeing a message (that error) being returned from the software on your droplet. This means that your droplet is online and running, and that the problem exists inside with the software that you manage.
Now, with that as the framework, I am here to offer advice. A 502 bad gateway error means that the front-end application failed to reach a back-end application. The front-end application is usually a web server, something like Nginx or Apache. The back-end application could be literally anything, commonly anything from PHP-FPM to a NodeJS app. What the 502 error doesn’t tell you is what the back-end application is, and how you resolve an issue with the back-end application is entirely relative to what that application is, which is something I do not know.
If you know what that back-end application is, chances are you need to restart it and review it’s logs to find out why it failed. Here you can find some tips on restarting services:
If all of your applications are set to start on boot, rebooting your droplet might bring everything back online, but also gives you no insight into the reason it occurred.
If you are not sure what the back-end application is, you can gain more insight by reviewing the logs of the front-end application, which is most likely a web server. Here you can find some reading that may help to understand how to review logs: