Wordpress: Loopback request and REST API fail in Site Health Status when using a reverse proxy or different port

[ghost]

I use WordPress (fpm-alpine) together with Nginx in the backend with HTTP on port 80. In front of that I have the caddy reverse proxy running, although this applies to any other reverse proxy.

                             +------------------+         +------------------+
                             |      caddy       |         |       nginx      |
https://example.org +-------->                  +-------->+                  |
                             |  172.18.0.2:443  |         |   172.18.0.3:80  |
                             +------------------+         +------------------+

The installation of WordPress and plugins works fine, but the Site Health Status (/wp-admin/site-health.php) shows that the Loopback request and REST API fail with following error:
Error: cURL error 28: Failed to connect to example.org port 443: Operation timed out (http_request_failed)

This can be partially fixed by redirecting the domain of the site (example.org) to the IP of the reverse proxy (172.18.0.2) using extra_hosts to docker-compose.yml:

    extra_hosts:
      - "example.org:172.18.0.2"
      - "example.org:fd00::2"

Then cURL tries to connect to the correct domain but still fails:
Error: cURL error 28: Operation timed out after 10001 milliseconds with 0 bytes received (http_request_failed)

There is a tedious workaround which you can try to prevent these errors to occur. By changing the Nginx backend port to the same which port is used by the visitors domains (example.org), which in this case is the default HTTPS port 443. To do that I had to create a self-signed certificate and change some settings related to SSL in the backend Nginx server. After doing there were no errors. But as I've said, this is a workaround and not a fix. The error itself is not related to SSL, but rather to the port that is used.

docker-compose.yml:

version: '3.8'

services:
  caddy:
    image: caddy/caddy:alpine
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile
      - ./caddy/data:/data

  nginx:
    image: nginx:alpine
    volumes:
      - ./nginx:/etc/nginx
      - ./www:/var/www/html

  wordpress:
    image: wordpress:fpm-alpine
    env_file: .env
    volumes:
      - ./www:/var/www/html
    extra_hosts:
      - "example.org:172.18.0.2"
      - "example.org:fd00::2"

  mariadb:
    image: mariadb:latest
    env_file: .env
    volumes:
      - ./mariadb:/var/lib/mysql

nginx.conf:

user nginx;
worker_processes auto;
pid /var/run/nginx.pid;

events {
  worker_connections 1024;
}

http {
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  charset UTF-8;
  sendfile on;

  set_real_ip_from caddy;
  real_ip_header X-Forwarded-For;

  server {
    listen 80;
    listen [::]:80;
    server_name _;
    root /var/www/html;
    index index.php;

    location / {
      try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
      include fastcgi.conf;
      fastcgi_pass wordpress:9000;
    }
  }
}

I have also tested this using plain HTTP locally without a reverse proxy. When using Docker port 80 and Nginx port 80 everything works. But when binding any port with Docker that Nginx doesn't use, the same error happens. Here is a docker-compose.yml configuration which causes the same error to occur:

docker-compose.yml:

...
  nginx:
    image: nginx:alpine
    ports:
      - 127.0.0.1:8080:80
...

[tianon]

This seems like a very complicated way to deploy -- is there a particular reason you're using two separate reverse proxies instead of just one? (Either of Caddy or NGINX should be able to do what you need without the other.)

I'd also suggest trying the Docker Community Forums, the Docker Community Slack, or Stack Overflow -- the issues here aren't intended to be a dedicated support forum, and I really don't see what we could change in the WordPress image to alleviate the issue you're seeing (I think it's likely related to the complexity of your container networking topology).

[ghost]

I use multiple reverse proxies because it makes it easier to deploy multiple services. I think my issue is still relevant as it not only applies to reverse proxies with different backend ports, but also when simply running a webserver such as Nginx with a different port number (see the last section of my issue). It should be possible to run WordPress on a different port with Nginx or other webservers.

[yosifkit]

I think this is outside the scope of the wordpress image. These issues are meant to cover bugs with the Docker image and not a generic support forum.

This issue is about configuring WordPress to work correctly behind multiple proxies. So I think you'd probably need the equivalent of some of these? Or try asking on the WordPress Support pages (or links @tianon gave above)?

• http://www.feliciano.tech/blog/running-wordpress-behind-an-sslhttps-terminating-proxy/
• https://wordpress.org/support/topic/wp-behind-apache-reverse-proxy/
• https://wordpress.org/support/topic/what-is-the-url-used-for-the-loopback-curl-check/

---

As for the port changing 127.0.0.1:8080:80 that is very similar to running WordPress behind an ssl terminating reverse proxy, so I would guess that WordPress needs to be informed what the site url is including port (and X-Forwarded-Proto when changing from ssl to non-ssl);

[ghost]

I take back what I said, my problems were caused by a faulty plugin I had installed. Thanks for the help nevertheless.

[adkondr]

Tell me, what solution is working now?