--- title: "502 Bad Gateway error in Nginx: causes and how to fix it | StreetHosting" description: "Learn what the 502 Bad Gateway error in Nginx means, read the error.log, find the cause (stopped app, wrong port, PHP-FPM, low RAM) and how it differs from 504." url: "https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error" type: "page" language: "en-US" --- VPS · 9 min · Intermediate Published on Nov 13, 2026 · Updated on Nov 13, 2026 # 502 Bad Gateway error in Nginx: how to find the cause and fix it A 502 means Nginx tried to talk to your application and did not get a valid response. See how to read the error log, what each message means and the most common causes, from a stopped app to running out of memory. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Errors and diagnostics](https://streethosting.com.br/en/guides/topics/troubleshooting) [Network, DNS and domains](https://streethosting.com.br/en/guides/topics/networking) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=502%20Bad%20Gateway%20error%20in%20Nginx%3A%20causes%20and%20how%20to%20fix%20it&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error "Share on LinkedIn") [](https://wa.me/?text=502%20Bad%20Gateway%20error%20in%20Nginx%3A%20causes%20and%20how%20to%20fix%20it%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fnginx-502-bad-gateway-error "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error.md) In this guide 8 sections * [What a 502 means](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#o-que-e) * [Read Nginx's error.log](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#log) * [A stopped or hung application](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#app-parado) * [Wrong port or address in proxy\_pass](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#endereco) * [The PHP-FPM socket](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#php-fpm) * [An application restarting for lack of RAM](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#memoria) * [502 or 504: what is the difference](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#504) * [Where to run this at StreetHosting](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#onde-rodar) Quick answer A **502 Bad Gateway** error means Nginx did not get a valid response from the server behind it, the _upstream_: your application, a container or PHP-FPM. To find the cause, run `sudo tail -n 50 /var/log/nginx/error.log` and read the message. The most common causes are a stopped application, a wrong port or address in `proxy_pass`, a PHP-FPM socket with the wrong path or permission and the application being killed for lack of memory. A 504 is a different problem: the upstream answered too slowly. ## What a 502 means[](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#o-que-e) When Nginx works as a reverse proxy, it receives the visitor's request and passes it to another program: a Node.js application, a Python server, a Docker container, PHP-FPM. That program behind it is the **upstream**. The 502 code is Nginx's way of saying the conversation with the upstream went wrong: it could not connect, or it connected and got something that is not a valid HTTP response, or the connection was cut halfway. The practical upside is that the error is almost always in the application or in the link between it and Nginx, not in Nginx. And Nginx always writes the exact reason to its error log. The basic proxy setup is in the [Nginx reverse proxy guide](https://streethosting.com.br/en/guides/vps/nginx-reverse-proxy-vps); here the focus is diagnosing when it does not work. ## Read Nginx's error.log[](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#log) Open the log live, trigger the error in the browser and read the new line: `sudo tail -f /var/log/nginx/error.log # or just the latest upstream entries sudo grep upstream /var/log/nginx/error.log | tail -n 20` Each message points to a different cause. The most common ones: * **connect() failed (111: Connection refused) while connecting to upstream:** Nginx reached the address, but nothing was listening on that port. The application is stopped, crashed or is listening on another port or another interface. * **no live upstreams while connecting to upstream:** you defined an upstream block and all of its servers were marked as down after consecutive failures. Nginx stops trying for a while. The real cause is the same as a refused connection: look at the error line before it. * **upstream prematurely closed connection while reading response header from upstream:** the connection opened, but the application closed it before answering. It is usually the process crashing mid-request, or the proxy speaking a different protocol from what the application expects (for example HTTP on a port that expects HTTPS). * **connect() to unix:/run/php/php8.3-fpm.sock failed (13: Permission denied):** Nginx found the socket, but its user does not have permission to use it. * **connect() to unix:... failed (2: No such file or directory):** the socket path is wrong, or the service that creates the socket is not running. * **recv() failed (104: Connection reset by peer):** the application dropped the connection abruptly, usually because of an internal error or because it was restarted. To investigate the application afterward, the [guide to logs on a VPS](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs) shows how to read journalctl and the service logs. ## A stopped or hung application[](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#app-parado) The number one cause. The application is not running, or it ran and died. Check its state according to how you start it: `# systemd service systemctl status my-app journalctl -u my-app -n 50 --no-pager # process managed by PM2 pm2 list pm2 logs my-app --lines 50 # Docker container docker ps -a docker logs --tail 50 my-app` If the service is stopped, its log shows why: a code error, a missing environment variable, a port already in use, the database being down. Fix the reason before simply restarting, or it will fall over again. And for the application to come back by itself after a VPS reboot, set the service up at boot: the [guide to PM2 with systemd](https://streethosting.com.br/en/guides/vps/pm2-vs-systemd-nodejs) and the one on [creating a systemd service](https://streethosting.com.br/en/guides/vps/create-systemd-service-linux) cover that. Then test the application without Nginx, straight on its own port. If the curl below answers, the problem is in the link; if it fails, it is in the application: `curl -I http://127.0.0.1:3000` ## Wrong port or address in proxy\_pass[](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#endereco) See where the application really listens and compare it with what Nginx uses: `sudo ss -tlnp | grep -E ':3000|:8000|:8080' sudo nginx -T | grep proxy_pass` The ss output shows the address and port of every listening process. The typical problems: * **A different port:** the application starts on 3001 and proxy\_pass points at 3000. Common after changing the port in the code or in the environment file. * **Listening only on IPv6 or on another interface:** if ss shows `[::1]:3000`, the application listens only on local IPv6 and a proxy\_pass to 127.0.0.1 is refused. The opposite also happens. Align both sides, and prefer writing the numeric address in proxy\_pass instead of localhost, which may resolve to IPv6 or IPv4 depending on the system. * **An application in Docker listening on 127.0.0.1 inside the container:** inside the container, 127.0.0.1 is only itself, and the published port receives nothing. The application has to listen on 0.0.0.0, and the port has to be published in the compose file, for example `127.0.0.1:3000:3000`. * **The wrong protocol:** a proxy\_pass with https to a port that speaks plain HTTP, or the other way around, produces a closed upstream or an SSL handshake failure in the log. After adjusting, validate and reload: `sudo nginx -t sudo systemctl reload nginx` ## The PHP-FPM socket[](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#php-fpm) On PHP sites (WordPress, Laravel), the upstream is PHP-FPM, usually over a Unix socket. A 502 here is almost always one of these three things: 1. **PHP-FPM is stopped:** check with `systemctl status php8.3-fpm` (swap in the installed version) and restart if needed. 2. **The socket path changed:** the socket name includes the PHP version. After upgrading PHP, the old fastcgi\_pass points to a file that no longer exists. See the real path and compare it with the configuration: 3. **The socket permission does not let Nginx in:** the Nginx user (usually www-data) needs access to the socket. `ls -l /run/php/ grep -R "fastcgi_pass" /etc/nginx/sites-enabled/ grep -E "^(listen|user|group)" /etc/php/8.3/fpm/pool.d/www.conf` In the pool file, the `listen.owner` and `listen.group` lines define who can use the socket, and `listen.mode` the mode. The Ubuntu default already uses www-data, so the permission error usually shows up when Nginx runs as another user or when the socket was moved to a folder without access. If PHP-FPM listens on a port (127.0.0.1:9000), fastcgi\_pass has to use the same address. ## An application restarting for lack of RAM[](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#memoria) If the 502 comes and goes, or shows up under load, suspect memory. When RAM runs out, the Linux kernel picks a process and kills it (the OOM killer). Often it is exactly your application or the database. The service restarts by itself, and during those seconds Nginx returns a 502. Confirm it: `sudo dmesg -T | grep -i -E "out of memory|killed process" sudo journalctl -k | grep -i oom free -h` A line such as `Out of memory: Killed process 1234 (node)` confirms the cause. The ways out, from cheapest to most definitive: * **Set up swap** to give breathing room during peaks. It is no miracle, but it keeps the process from dying in short moments of pressure. The walkthrough is in the [guide to swap on Ubuntu](https://streethosting.com.br/en/guides/vps/set-up-swap-ubuntu-vps). * **Reduce consumption:** fewer application processes, a Node memory limit, fewer simultaneous database connections, a leaner cache. * **Increase the VPS RAM:** if normal usage is already near the limit, this is the right path. Do not fix the 502 just by making the application restart every time it falls. That hides the symptom and leaves the memory problem coming back under load. Find out what is eating the RAM. ## 502 or 504: what is the difference[](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#504) Both appear in front of Nginx and get mixed up, but they tell different stories: * **502 Bad Gateway:** Nginx could not get a valid response. The connection was refused, the upstream closed before answering or it answered something invalid. It points to a down application or a wrong address or socket. * **504 Gateway Timeout:** Nginx connected, waited and the upstream did not answer within the limit (`proxy_read_timeout`, 60 seconds by default). The log shows `upstream timed out (110: Connection timed out)`. It points to a slow application, a heavy query or a stuck process. Raising the timeout only makes sense if the work legitimately takes long, such as generating a report. For an application that hangs, the way forward is to find the bottleneck, not to hide the wait. A short routine for any 502: read the last upstream line in the error.log, test the application with curl straight on its port, check the service state, compare the port or socket with what Nginx uses and, if it is intermittent, look at dmesg for a lack of memory. ## Where to run this at StreetHosting[](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#onde-rodar) Diagnosing a 502 takes reading system logs, checking open ports, querying dmesg and restarting services, all with root access. On StreetHosting VPS plans the virtualization is KVM, with its own kernel and root, in São Paulo, so the commands in this guide work as shown, dmesg included for tracking down crashes from memory. If the problem is recurring lack of RAM, the Ryzen 9 9950X VPS has plans from 2 GB up to 64 GB with DDR5 memory, and the [VPS page](https://streethosting.com.br/en/vps) shows the available configurations. All of them include AntiDDoS and a dedicated IPv4. In this guide * [What a 502 means](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#o-que-e) * [Read Nginx's error.log](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#log) * [A stopped or hung application](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#app-parado) * [Wrong port or address in proxy\_pass](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#endereco) * [The PHP-FPM socket](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#php-fpm) * [An application restarting for lack of RAM](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#memoria) * [502 or 504: what is the difference](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#504) * [Where to run this at StreetHosting](https://streethosting.com.br/en/guides/vps/nginx-502-bad-gateway-error#onde-rodar) ## Frequently asked questions What does 502 Bad Gateway mean in Nginx? It means Nginx, acting as a proxy, tried to talk to the server behind it (the upstream, such as a Node or Python application or PHP-FPM) and did not get a valid response. The problem is almost never in Nginx itself, but in the application, the address it uses or the communication between the two. Where is the log that explains the 502? On the default Ubuntu Nginx, in /var/log/nginx/error.log. Run sudo tail -n 50 /var/log/nginx/error.log right after triggering the error and read the last line containing the word upstream. It gives the address Nginx tried and the reason it failed. What is the difference between 502 and 504? With a 502, Nginx got an invalid response or could not connect to the upstream. With a 504, the upstream took longer than the wait limit to answer, usually after accepting the connection. A 502 points to a down app or a wrong address, and a 504 to a slow or stuck app. Why does the 502 only show up sometimes? Almost always because the application goes down and comes back. A crash from lack of memory, a service restart during a deploy or a process that hangs under load make Nginx fail while the app is offline and succeed when it returns. Check dmesg and the service's own log. Does restarting Nginx fix the 502? Rarely. Nginx is usually healthy, and what fails is what sits behind it. Before restarting anything, check that the application is running and listening on the port proxy\_pass uses. After changing the configuration, use nginx -t and reload with systemctl reload nginx. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) ## Related guides [VPS Intermediate How to set up Nginx as a reverse proxy on a VPS Your app runs on an internal port and you want to serve it on a domain with HTTPS. Nginx as a reverse proxy solves that and also brings several apps together in one place. 3 min Read guide](https://streethosting.com.br/en/guides/vps/nginx-reverse-proxy-vps) [VPS Intermediate How to set up swap on Ubuntu on a VPS Swap does not replace RAM, but it helps during peaks and can keep services from crashing when memory runs out. 2 min Read guide](https://streethosting.com.br/en/guides/vps/set-up-swap-ubuntu-vps) [VPS Intermediate How to analyze Linux VPS logs with journalctl and grep Almost every server problem leaves a trace in some log. See where each record lives on Ubuntu, how to slice by service, time and severity, and how to keep logs from filling the disk. 9 min Read guide](https://streethosting.com.br/en/guides/vps/analyze-linux-vps-logs) [← Back to the Guide Center](https://streethosting.com.br/en/guides)