Parse-server: nginx 404 proxying parse-server requests (digitalocean ubuntu)

[psparago]

(cross-posted on stack overflow)

I am migrating parse-server to a DigitalOcean Ubuntu droplet based on this documentation:

How To Migrate a Parse App to Parse Server on Ubuntu 14.04

I'm having an issue with nginx proxying (https) requests to parse-server.

If I open port 1337 on my droplet and configure Parse http requests to go directly to parse-server (http://example.com:1337/parse), this all works as expected.

If I configure Parse http requests to go to https://example.com/parse, nginx fails to proxy the request to parse-server.

nginx returns a 404 (which is suspiciously what the / location will do).

The Let's Encrypt SSL cert seems to be working as expected, as I can serve static content (http requests are redirected from 80 to 443 via 301 status).

My nginx default configuration looks like this:

# HTTP - redirect all requests to HTTPS
server {
    listen 80;
    listen [::]:80 default_server ipv6only=on;
    return 301 https://$host$request_uri;
}

# HTTPS - serve HTML from /usr/share/nginx/html, proxy requests to /parse/
# through to Parse Server
server {
    listen 443;
    server_name example.com;

    root /usr/share/nginx/html;
    index index.html index.htm;

    ssl on;
    # Use certificate and key provided by Let's Encrypt:
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_session_timeout 5m;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

    # Pass requests for /parse/ to Parse Server instance at localhost:1337
    location /parse/ {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-NginX-Proxy true;
            proxy_pass http://localhost:1337/;
            proxy_ssl_session_reuse off;
            proxy_set_header Host $http_host;
            proxy_redirect off;
    }

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

This is a typical line from nginx access.log:

xxx.xxx.xxx.xxx - - [20/Mar/2016:18:54:53 -0400] "PUT /parse/classes/_User/xxxxxxxxxx HTTP/1.1" 404 68 "-" ...

Is there any way to turn more verbose debugging on so I can tell why the match is failing?

Thanks, peter

[flovilmart]

proxy_pass http://localhost:1337/;

did you try proxy_pass http://localhost:1337/parse/;

[psparago]

@flovilmart Yes. I did. It didn't make any difference. (I don't think it's getting to parse-server at all)

Thank you for the suggestion.

[davimacedo]

The following is work fine for me:

server {
        listen 443;
        server_name parseapi.back4app.com;

        include /etc/nginx/include.d/ssl.conf;

        charset utf-8;

        # enable 10 mega max upload size
        client_max_body_size 10m;

        location / {
                include /etc/nginx/include.d/cors.conf;

                proxy_pass http://127.0.0.1:6000;
                proxy_set_header Host $http_host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
        }
}

[psparago]

@davimacedo Yes, that does work, thank you.

I hate to be greedy :-), but eventually, this droplet will handle requests other than /parse requests. I will eventually need to figure out why I can't proxy more than one location. I assume that's possible.

[flovilmart]

@psparago you can also mount parse-server on / and use subdomain routing like api.example.com

[psparago]

@flovilmart That would be a very good alternative. Thank you.

[psparago]

@davimacedo Oops! Using only the / location only breaks serving static content. I'm going to have to probably have to use the subdomain route if I can't figure out the location issue.

[flovilmart]

@psparago you should not need to go that route, nginx is perfectly capable of doing what you're expecting.

[psparago]

@flovilmart I agree. It's both baffling and frustrating. I'm so close! I wish I could find a way to log the match process. I'm sure it would be obvious, but I took this code pretty much directly from the migration instructions. It must be working for somebody! :-)

[davimacedo]

@psparago you can try something like this:

...
location = /parse {
                ...
                proxy_pass http://localhost:1337/;
                ...
        }

location / {
            root /usr/share/nginx/html;
            try_files $uri $uri/ =404;
    }
...

Create a subdomain only to handle parse api requests seems to be a good option for me. Other option is to handle the static files in your node.js app.

[psparago]

@flovilmart Your answer above was the solution. I think the reason that it did not work when I allegedly "tried it", was that I didn't have the trailing slash on http://localhost:1337/parse/. My apologies for the inaccuracy. Thank you.

[flovilmart]

glad you found a proper solution

[HemanParbhakar]

What is the version of nginx that has to being used

[psparago]

@Heman6886 I installed nginx/1.4.6 (Ubuntu)

[majidhassan]

Hey, I seem to have a similar problem.

I installed parse-server on DigitalOcean using this script, which I had created based on the DigitalOcean tutorials. It was working fine up until two days ago, although I had not made any changes to the script itself.

Parse-server and dashboard are running on the machine, and I can make HTTP requests to my parse-server locally using curl, and I have no problems doing the migration using mongodb://

But, when I come to access my server through HTTPS (whether I'm accessing /parse or /dashboard) nothing seems to get through. I'm not even getting any entries in nginx's access or error logs.

The ssl certificates are created with letsencrypt and seem to be fine as well.

My environment:

ubuntu 14.04
nginx 1.4.6
parse-server 2.2.16
parse-dashboard 1.0.14

[flovilmart]

What is your nginx configuration?

[majidhassan]

# HTTP - redirect all requests to HTTPS
server {
    listen 80;
    listen [::]:80 default_server ipv6only=on;
    return 301 https://;
}
# HTTPS - serve HTML from /usr/share/nginx/html, proxy requests to /parse/
# through to Parse Server
server {
        listen 443;
        server_name mydomain.com;
        root /usr/share/nginx/html;
        index index.html index.htm;
        ssl on;
        # Use certificate and key provided by Let's Encrypt:
        ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
        # Pass requests for /parse/ to Parse Server instance at localhost:1337
        location /parse {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass http://localhost:1337/parse/;
                proxy_ssl_session_reuse off;
                proxy_set_header Host $http_host;
                proxy_redirect off;
        }
        location /dashboard {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass https://localhost:4040/dashboard/;
                proxy_ssl_session_reuse off;
                proxy_set_header Host $http_host;
                proxy_redirect off;
        }
        location / {
                try_files  / =404;
        }
}

[majidhassan]

Found it. Last lines should be:

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

The script was not escaping the "$" in uri. Why this was working two days ago is beyond me.