Shopware with Reverse Proxy

Sometimes you have more than just a simple Shpoware instance in your development environment. In this case you usually use a reverse proxy that handles routing to your local services. And this requires more configuration for your tunnel setups inside the proxy to handle our domains.

But it can also be, that you need webhooks for multiple services. In this case you also need to make sure that the tunnel requests are routed correctly to the correct target system.

As you see, there are different use cases.

The good thing is that you can solve all of them, but you need a bit more knowledge on this of course.

This page helps you to dig deeper into proxy configuration options, so that you still end up with a nice plug'n'play environment for your developers.

1. Local Environment

Let's start with a sample environment based on Docker.

It contains a Shopware shop, an additional service (could be a Symfony application) and a reverse proxy based on NGINX.

The local development machine has 2 domains in /etc/hosts

• shop.local-domain.com

• symfony.local-domain.com

Once our developer opens these domains, the proxy (with port 80 and 443) is being called. Thanks to both bind-mounted configuration files, it will either forward the request to the Shopware shop, or to the Symfony application container.

docker-compose.yml

version: "3.0"

services:

    proxy:
       container_name: proxy
       image: dockware/proxy:latest
       ports:
         - 80:80
         - 443:443
       depends_on:
         - shop
         - symfony
       volumes:
         - "shop.conf:/etc/nginx/conf.d/shop.conf"
         - "symfony.conf:/etc/nginx/conf.d/symfony.conf"
    shop:
       container_name: shop
       image: dockware/dev:6.5.3.1
       
    symfony:
       container_name: symfony
       image: dockware/flex:latest

shop.conf

server {
    listen        80;
    server_name   shop.local-domain.com;
    return 301    https://$host$uri$is_args$args;
}

server {
    listen        443 ssl;
    server_name   shop.local-domain.com;

    ssl_certificate /etc/nginx/ssl/selfsigned.crt;
    ssl_certificate_key /etc/nginx/ssl/selfsigned.key;

    location / {
        proxy_pass https://shop;
    }
}

symfony.conf

server {
    listen        80;
    server_name   symfony.local-domain.com;
    return 301    https://$host$uri$is_args$args;
}

server {
    listen        443 ssl;
    server_name   symfony.local-domain.com;

    ssl_certificate /etc/nginx/ssl/selfsigned.crt;
    ssl_certificate_key /etc/nginx/ssl/selfsigned.key;

    location / {
        proxy_pass https://symfony;
    }
}

2. Start Tunnel

NGROK

If you use NGROK for your tunnels, please see the following sections. If you are not yet familiar with NGROK you might want to check it out here: https://ngrok.com/

ngrok http --region=eu 443

Cloudflare

If you use Cloudflare for your tunnels, please see the following sections. Once Cloudflare is installed, you can easily start it using this command.

cloudflared tunnel --no-tls-verify --url=https://localhost

3. Tunnel NGINX Configuration

Let's create a new file tunnels.conf for our NGINX.

We have to adjust our docker-compose.yml and add it to the bind mounted files of the proxy (don't forget to restart the whole Docker containers at the end of this tutorial).

volumes:
   ....
   - "tunnels.conf:/etc/nginx/conf.d/tunnels.conf"
   ...

The content of the tunnels.conf file (configuration below) makes sure that NGINX listens to both possible domain endings ngrok-free.app and trycloudflare.com (please adjust to your domains if you use something else).

If the proxy receives such a request, it will pass on the request to our containers.

If we receive a request starting with /webhook, the request is passed on to our Symfony application. But before we do this, the Host is being adjusted to symfony.local-domain.com. We only need to do this in case our Symfony application really listens to that incoming domain. Most simple PHP applications don't really care, and would just process the request.

Every other request is being passed on to Shopware. But why do we have the host set to $HTTP_SQUADDNS_HOST? This is another and dynamic way of setting our host. We decided on using our static domain for our Shopware. Because we only have 1 static domain, we don't have a separate one for Symfony of course, so we just set the Host to be the value that Symfony requires (in case it even does).

But for the shop, we can use the originally used domain from SquadDNS.

The actual Host variable in NGINX that is being received, is the NGROK or Cloudflare host, because the tunnels overwrite that entry. SquadDNS saves the original domain in a separate header, so you can use it if you need it, even though a tunnel service is in-between.

server {
    listen        80;
    server_name   *.ngrok-free.app *.trycloudflare.com;
    return 301    https://$host$uri$is_args$args;
}

server {
    listen        443 ssl;
    server_name   *.ngrok-free.app *.trycloudflare.com;

    ssl_certificate /etc/nginx/ssl/selfsigned.crt;
    ssl_certificate_key /etc/nginx/ssl/selfsigned.key;

    location /webhook {
        proxy_set_header Host   symfony-local-domain.com; # might be optional
        proxy_pass              https://symfony;
    }

    location / {
        proxy_set_header Host   $HTTP_SQUADDNS_HOST; # required by Shopware Sales Channel domain recognition
        proxy_pass              https://shop;
    }
}

Attention, you can already set the header you want to be used when starting the tunnel. >> ngrok http --host-header={my-hostname} 443 (also works for Cloudflare). In this case all requests will be received from our proxy, already with this server name. So instead of listening to the * ngrok and cloudflare domains, you can already listen to your static domain in NGINX.

It's up to you to decide what way to go. While starting the tunnel already with the correct host gives an easier flow, the other approach helps to centralize the "magic" within the NGINX configuration file only.

Don't forget. If you really want to use the Shopware shop from remote in the browser, you might also need to adjust the sales channel domains to match your static domain!

4. Update SquadDNS

The only thing that's left to do is, to copy the generated tunnel domain and add it to your record inside SquadDNS.

That's it! You can now use your static domain for both the Symfony application (/webhook) as well as the Shop system.