NGINX Reverse Proxy Issue: Shopify Confirmation Page Redirects to myshopify.com Instead of Custom Domain

Other Questions Shopify
1

I’m running into a problem with my NGINX reverse proxy setup on Heroku. I’m using it to route traffic to my Shopify store while maintaining my custom domain.

My current NGINX setup looks like this:

upstream backend {
    server unix:/tmp/app.socket fail_timeout=0;
}

server {
    listen <%= ENV["PORT"] %>;
    server_name _;
    keepalive_timeout 5;
    port_in_redirect off;

    location / {
        proxy_pass https://mystore.myshopify.com;

        client_max_body_size    15m;
        client_body_buffer_size     256k;
        proxy_connect_timeout 120;

        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location ~ ^/(browse|products)/? {
        proxy_pass http://backend;
        proxy_redirect off;

        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    }
}

The proxy works fine for most of the shopping experience. Customers are able to browse products, add items to their cart, and complete the checkout using my custom domain without any problems.

But here’s where it breaks: After payment is processed, Shopify automatically sends users to a confirmation page. Instead of keeping my custom domain, it redirects them to a URL with the myshopify.com domain. This causes the page to not load correctly.

If I manually edit the URL to use my custom domain instead of the myshopify one, the confirmation page works perfectly. I’ve been trying different NGINX settings for a few days but can’t figure out how to fix this redirect issue.

Has anyone dealt with this before? Any suggestions would be really helpful.

2

You’re missing headers that Shopify needs for proper URLs. Add proxy_set_header X-Forwarded-Proto $scheme; and proxy_set_header X-Forwarded-Host $host; to your main location block. Shopify uses these to figure out what domain to use for redirects and absolute URLs. I’ve seen this exact issue before - checkout works fine but post-payment pages break because Shopify falls back to its default domain when it can’t detect the forwarded host info. Also check that you’re passing through Shopify-specific cookies properly since the confirmation page needs session data from checkout.

3

Check if you’re using the sub_filter directive - it rewrites response content on the fly. Try something like sub_filter 'mystore.myshopify.com' 'yourcustomdomain.com'; to catch confirmation page links that other headers miss. Worked for me when proxy_redirect wasn’t enough.

4

This happens because Shopify generates URLs server-side after payment processing with hardcoded domain references. I ran into the same thing when proxying a store - the confirmation page completely ignores proxy headers since it’s built on Shopify’s end. Beyond the header fixes already mentioned, you’ll need to tweak your NGINX config for those specific confirmation paths. Add a location block like location ~* ^/.*/(orders|thank_you|checkouts).*$ with tighter proxy settings. Also check if your theme or checkout settings have any hardcoded domain references that might be messing with the proxy during post-payment.

5

i had a similar prob too! try adding proxy_set_header Host mystore.myshopify.com; in your main location block. it seriously helped me fix the redirect issue.

6

This happens because Shopify’s confirmation page creates absolute URLs with the original shop domain. Had the exact same problem when I set up a reverse proxy for a client. Add proxy_redirect https://mystore.myshopify.com/ /; to your main location block. This makes NGINX rewrite the Location headers in Shopify’s responses - it converts those myshopify.com URLs back to your custom domain. You might need to handle multiple redirect patterns since Shopify uses different URL structures. Test it thoroughly with real purchases though - some payment gateways mess with redirect handling.