Nginx: (111: Connection refused) while connecting to upstream wordpress & docker - wordpress

Question

As many people I have the problem with the following error when I call the website (blog.mydomain.de):
502 Bad Gateway
nginx/1.14.2
2020/03/14 23:59:08 [error] 7#7: *1 connect() failed (111: Connection refused) while connecting to upstream, client: $IP, server: blog.mydomain.de, request: "GET / HTTP/2.0", upstream: "https://192.168.160.5:443/", host: "blog.mydomain.de"
So my problem is using WordPress. I also show you the NextCloud config because this works without any problems. I also know that the WordPress nginx config should contain more but I tried to find it if I even get this error with minimal config missing fastcgi and stuff.
worker_processes auto;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 1024;
}
http {
gzip on;
gzip_min_length 1000;
gzip_proxied expired no-cache no-store private auth;
gzip_types text/plain text/css text/xml
application/javascript application/json application/xml application/rss+xml image/svg+xml;
server_names_hash_bucket_size 64;
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
more_clear_headers 'server';
ssl_certificate /etc/letsencrypt/live/mydomain.de-0001/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.de-0001/privkey.pem;
ssl_trusted_certificate /etc/letsencrypt/live/mydomain.de-0001/chain.pem;
ssl_dhparam /etc/ssl/dhparam.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_ciphers "EECDH-AESGCM:EDH+ESGCM:AES256+EECDH:AES256+EDH";
ssl_prefer_server_ciphers on;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";
server {
listen 80;
listen [::]:80;
server_name blog.mydomain.de cloud.mydomain.de;
return 301 https://$host$request_uri;
#return 301 https://$server_name$request_uri;
}
# NextCloudPi
server {
server_name cloud.mydomain.de;
listen 443 ssl http2;
listen [::]:443 ssl http2;
client_max_body_size 100G;
underscores_in_headers on;
location / {
proxy_headers_hash_max_size 512;
proxy_headers_hash_bucket_size 64;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
add_header Front-End-Https on;
proxy_pass https://nextcloudpi;
}
}
# NextCloudPi Konfiguration Web-Interface
server {
server_name cloud.mydomain.de;
listen 4443 ssl http2;
listen [::]:4433 ssl http2;
location / {
more_clear_headers 'upgrade';
more_clear_headers 'Strict-Transport-Security';
proxy_ssl_verify off;
proxy_pass https://nextcloudpi:4443;
proxy_pass_header Authorization;
proxy_set_header 'X-Forwarded-Host' cloud.mydomain.de;
proxy_set_header 'X-Forwarded-Proto' https;
proxy_set_header 'X-Forwarded-For' $remote_addr;
proxy_set_header 'X-Forwarded-IP' $remote_addr;
}
}
# WordPress
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name blog.mydomain.de;
client_max_body_size 200m;
underscores_in_headers on;
location / {
proxy_pass http://wordpress;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
}
}
}
I'm using this with docker containers. The compose file looks like this:
version: "3"
networks:
nextcloudpi:
services:
nginx:
restart: always
container_name: nginx
image: cptdaydreamer/nginx:latest
ports:
- 80:80
- 443:443
- 4443:4443
- 6800:6800
volumes:
- /media/storage/nginx:/var/log/nginx
- /etc/ssl:/etc/ssl
- /etc/letsencrypt/live:/etc/letsencrypt/live
- /etc/letsencrypt/archive:/etc/letsencrypt/archive
links:
- wordpress
depends_on:
- nextcloudpi
networks:
- nextcloudpi
- default
nextcloudpi:
restart: always
container_name: nextcloudpi
image: cptdaydreamer/nextcloudpi:latest
expose:
- 80
- 443
- 4443
- 6800
volumes:
- /media/storage/data:/data
- /etc/localtime:/etc/localtime:ro
networks:
- nextcloudpi
portainer:
image: portainer/portainer
command: -H unix:///var/run/docker.sock
restart: always
ports:
- 9001:9000
- 8000:8000
volumes:
- /var/run/docker.sock:/var/run/docker.sock
- /media/storage/portainer:/data
container_name: portainer
db:
container_name: mariadb
image: mariadb:latest
#ports:
# - 3306:3306
volumes:
- /media/storage/mariadb:/var/lib/mysql
restart: always
environment:
MYSQL_ROOT_PASSWORD: $PRIVATE
MYSQL_DATABASE: $PRIVATE
MYSQL_USER: $PRIVATE
MYSQL_PASSWORD: $PRIVATE
wordpress:
container_name: wordpress
links:
- db
#ports:
# - 9000:9000
depends_on:
- db
image: wordpress:latest
expose:
- "80"
restart: always
volumes:
- /media/storage/wordpress:/var/www/html
environment:
WORDPRESS_DB_HOST: db:3306
#WORDPRESS_DB_HOST: db
WORDPRESS_DB_USER: $PRIVATE
WORDPRESS_DB_PASSWORD: $PRIVATE
WORDPRESS_DB_NAME: $PRIVATE
WORDPRESS_TABLE_PREFIX: $PRIVATE
I don't know what the exact problem is. The logs of the docker container of wordpress shows:
[15-Mar-2020 00:50:24] NOTICE: fpm is running, pid 1
[15-Mar-2020 00:50:24] NOTICE: ready to handle connections
Any ideas?
Updated on request:
Wordpress image is now latest instead of 7.3-fpm
Current used nginx.conf

Answer 1

Try edit to wordpress:9000 in the proxy pass script and change the Nginx config to this.
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass wordpress:9000;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param SCRIPT_NAME $fastcgi_script_name;
}
There's a mistake in your understanding. The wordpress-php-fpm image just expose the PHP-FPM service at port 9000, nothing running at https://wordpress:443 so Nginx will throw the 502 status. That's why you should use the fastcgi_pass to connect to PHP-FPM instead of proxy_pass like NextCloud API expose the https at port 4443 already.
When you split your stacks to 2 docker-compose.yml, everything will become more clearly and seperately.
-- wordpress/
--- docker-compose.yml
--- data/
-- nextcloud/
--- docker-compose.yml
--- data/
This is how Docker works.
From my experience, when using Docker, just keep a stack standalone. I mean Nextcloud going with an database, good. Then make another stack with WordPess and another database instance. It's take all the advantage of Docker and seperate the application each other.