How to configure NGINX conf location to work with AWS ALB? I have a docker-compose that simulates a staging environment that is deployed to AWS ECS, that works fine, status 200 OK:

/review-staging               200 OK
/review-staging/wp-admin      200 OK
/review-staging/graphql       200 OK

Although this works great through Docker-compose setup, the same does not happen once I run the requests against the AWS version, for one particular path tested so far /review-staging/wp-admin. As follows:

/review-staging               200 OK
/review-staging/wp-admin      302 fail (Browser throws ERR_TOO_MANY_REDIRECTS)
/review-staging/graphql       200 OK

The CloudWatch logs shows serveral of these:

 17/Oct/2019:01:54:07 +0000 "GET /review-ci/wp-admin/index.php" 302

The NGINX conf file I have is:

server {
    listen 80;
    server_name foobar;

    root /var/www/html;
    index index.php index.html index.htm;

    charset UTF-8;
    autoindex off;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    client_max_body_size 200m;

    # Do not log access to these to keep the logs cleaner
    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }

    location = /apple-touch-icon.png {
        log_not_found off;
        access_log off;
    }

    location = /apple-touch-icon-precomposed.png {
        log_not_found off;
        access_log off;
    }

    location / {
      try_files $uri $uri/ =404;
    }

   location ~ /elbhealth {
        add_header Content-Type text/html;
        return 200 'OK';
    }

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

    # Fix for Firefox issue with cross site font icons
    location ~* \.(eot|otf|ttf|woff)$ {
        add_header Access-Control-Allow-Origin *;
    }

    # Deny access to any files with a .php extension in the uploads directory
    location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php-fpm:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location  ~ \.(js|css|png|jpg|woff|gif|ttf|ico|svg)$ {
      try_files $uri =404;
    }

}

My expectation is to have it working as it works in docker-compose setup.

How to configure NGINX conf location to work with AWS ALB? I have a docker-compose that simulates a staging environment that is deployed to AWS ECS, that works fine, status 200 OK:

/review-staging               200 OK
/review-staging/wp-admin      200 OK
/review-staging/graphql       200 OK

Although this works great through Docker-compose setup, the same does not happen once I run the requests against the AWS version, for one particular path tested so far /review-staging/wp-admin. As follows:

/review-staging               200 OK
/review-staging/wp-admin      302 fail (Browser throws ERR_TOO_MANY_REDIRECTS)
/review-staging/graphql       200 OK

The CloudWatch logs shows serveral of these:

 17/Oct/2019:01:54:07 +0000 "GET /review-ci/wp-admin/index.php" 302

The NGINX conf file I have is:

server {
    listen 80;
    server_name foobar;

    root /var/www/html;
    index index.php index.html index.htm;

    charset UTF-8;
    autoindex off;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    client_max_body_size 200m;

    # Do not log access to these to keep the logs cleaner
    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }

    location = /apple-touch-icon.png {
        log_not_found off;
        access_log off;
    }

    location = /apple-touch-icon-precomposed.png {
        log_not_found off;
        access_log off;
    }

    location / {
      try_files $uri $uri/ =404;
    }

   location ~ /elbhealth {
        add_header Content-Type text/html;
        return 200 'OK';
    }

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

    # Fix for Firefox issue with cross site font icons
    location ~* \.(eot|otf|ttf|woff)$ {
        add_header Access-Control-Allow-Origin *;
    }

    # Deny access to any files with a .php extension in the uploads directory
    location ~* /(?:uploads|files)/.*\.php$ {
        deny all;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php-fpm:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    location  ~ \.(js|css|png|jpg|woff|gif|ttf|ico|svg)$ {
      try_files $uri =404;
    }

}

My expectation is to have it working as it works in docker-compose setup.

• nginx

1 Answer 1

The problem happens because of the way AWS ALB works, or at least the way mine is setup (which seems to be quiet common practice to be fair), the Loadbalancer listens on HTTPS:443 and forwards to the target HTTP:80. The problem above err-too-many-redirects is related to an endless loop created by the target application. The user requests /wp-admin and an endless loop of forwards keeps going without ever resolving unless we force Wordpress administration to use SSL mode, which is possible by setting the parameter force ssl admin in the wp-config.php:

define('FORCE_SSL_ADMIN', true);

I found out about this after trying the PHP reserved variable for server https:

$_SERVER['HTTPS'] = 'on'

Both should help fix the problem, I say "help", because you may still find mixed content warning messages, etc, and some browsers may actually prevent the content (img, css, etc) from loading or even prevent rendering your application service. So, beware of any bad protocol smells (HTTP vs HTTPS) in your Wordpress database, etc - that's out of the scope for the case I exposed initially, that is the 302, but I hope it's helpful and takes you to the right direction if that happens to you.

The issue above is quite common given the AWS architecture that they have released a tutorial about a similar use case ( https://docs.aws.amazon/elasticloadbalancing/latest/application/load-balancer-listeners.html#redirect-actions ).