How can I fix this 502 Bad Gateway?

Explanation of the problem

The user is attempting to run a WordPress site in a Docker container on Ubuntu VPS using Nginx-Proxy. The user created a docker-compose.yml file to define the necessary services and their respective configurations. When executing docker-compose up, the user encounters an error

Troubleshooting with the Lightrun Developer Observability Platform

Getting a sense of what’s actually happening inside a live application is a frustrating experience, one that relies mostly on querying and observing whatever logs were written during development.
Lightrun is a Developer Observability Platform, allowing developers to add telemetry to live applications in real-time, on-demand, and right from the IDE.

• Instantly add logs to, set metrics in, and take snapshots of live applications
• Insights delivered straight to your IDE or CLI
• Works where you do: dev, QA, staging, CI/CD, and production

Start for free today

Problem solution for: How can I fix this 502 Bad Gateway?

Other popular problems with nginx-proxy

Problem 1: Incorrect Configuration of Upstream Server Ports One of the most common issues with nginx-proxy is an incorrect configuration of the upstream server ports. If the upstream server is not listening on the default port 80, then the nginx-proxy cannot detect it, and it will generate a config file that will make the proxy server go down. As a result, when the web browser tries to access the site, it will return a 502 bad gateway error.

The solution to this problem is to ensure that the upstream server is listening on the default port 80 or to modify the configuration of the nginx-proxy to detect the server on the specific port that it is listening on. In the docker-compose file, the VIRTUAL_PORT environment variable should be set to the port that the upstream server is listening on, and the port mapping in the ports section should be removed. For example:

version: '3'
services:
  app:
    image: your-app-image
    environment:
      VIRTUAL_HOST: your.domain.com
      VIRTUAL_PORT: 8080 # change to the actual port of your app
    expose:
      - "8080"
  nginx-proxy:
    image: jwilder/nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro

Problem 2: Incorrect Mounting of Docker Daemon Socket Another issue that can cause problems with nginx-proxy is an incorrect mounting of the Docker daemon socket. If the Docker daemon socket is not available to the nginx-proxy container, it will not be able to communicate with the Docker API and generate the necessary config files for the upstream servers.

To solve this issue, the Docker daemon socket must be mounted correctly into the nginx-proxy container. This can be done by adding the following line to the docker-compose file under the volumes section:

- /var/run/docker.sock:/tmp/docker.sock:ro

Here is an example of a docker-compose file with the correct mounting of the Docker daemon socket:

version: '3'
services:
  app:
    image: your-app-image
    environment:
      VIRTUAL_HOST: your.domain.com
    expose:
      - "80"
  nginx-proxy:
    image: jwilder/nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro

Problem 3: Absent Letsencrypt Container The final common issue with nginx-proxy is the absence of the letsencrypt container. Without the letsencrypt container, HTTPS cannot be made available, even if the site is listening on the default port 443.

The solution to this issue is to add the letsencrypt container to the docker-compose file. The letsencrypt container will generate and manage the SSL certificates required for HTTPS. The following code block shows an example of a docker-compose file with the letsencrypt container included:

version: '3'
services:
  app:
    image: your-app-image
    environment:
      VIRTUAL_HOST: your.domain.com
    expose:
      - "80"
  nginx-proxy:
    image: jwilder/nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
  letsencrypt:
    image: jrcs/letsencrypt-nginx-proxy-companion
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./data/letsencrypt:/etc/letsencrypt
    environment:
      NGINX_PROXY_CONTAINER: nginx-proxy

A brief introduction to nginx-proxy

Most popular use cases for nginx-proxy

1. Reverse Proxy Server: One of the primary uses of nginx-proxy is as a reverse proxy server. It can be used to route traffic from the internet to a backend server, such as a web application or API. By doing so, nginx-proxy can perform tasks such as load balancing, SSL termination, and serving static assets. Below is an example of a docker-compose.yml file that utilizes nginx-proxy as a reverse proxy server for a web application:

version: '3'
services:
  web:
    image: nginx:latest
    expose:
      - 80
    environment:
      - VIRTUAL_HOST=example.com
  proxy:
    image: jwilder/nginx-proxy
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    ports:
      - "80:80"
      - "443:443"

In this example, the web service is a simple nginx container that serves static files, while the proxy service is an instance of nginx-proxy that routes traffic to the web container based on the VIRTUAL_HOST environment variable.

2. Load Balancer: Another use of nginx-proxy is as a load balancer. It can distribute incoming traffic across multiple backend servers, improving performance and reliability. Below is an example of a docker-compose.yml file that utilizes nginx-proxy as a load balancer for a group of web servers:

version: '3'
services:
  web1:
    image: nginx:latest
    expose:
      - 80
    environment:
      - VIRTUAL_HOST=example.com
  web2:
    image: nginx:latest
    expose:
      - 80
    environment:
      - VIRTUAL_HOST=example.com
  proxy:
    image: jwilder/nginx-proxy
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DEFAULT_HOST=example.com

In this example, there are two web services that serve the same content, and the proxy service is configured to distribute traffic evenly between them. The DEFAULT_HOST environment variable tells nginx-proxy which backend servers to balance traffic between.

3. SSL Termination: Finally, nginx-proxy can be used as an SSL termination point, allowing traffic to be encrypted at the edge of the network. This can be useful in scenarios where backend servers do not support SSL, or where SSL termination is required for compliance reasons. Below is an example of a docker-compose.yml file that utilizes nginx-proxy as an SSL termination point for a web application:

version: '3'
services:
  web:
    image: nginx:latest
    expose:
      - 80
    environment:
      - VIRTUAL_HOST=example.com
      - LETSENCRYPT_HOST=example.com
      - LETSENCRYPT_EMAIL=email@example.com
  proxy:
    image: jwilder/nginx-proxy
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
      - ./proxy/certs:/etc/nginx/certs
    ports:
      - "80:80"
      - "443:443"
    environment:
      - DEFAULT_HOST=example.com

In this example, the web service is configured with VIRTUAL_HOST, LETSENCRYPT_HOST, and LETSENCRYPT_EMAIL environment variables, which tell nginx-proxy to route traffic to this container and generate SSL certificates using the Let’s Encrypt service. The proxy service is configured with a `cert