In most setups I have seen, the nginx instance provided by Lemmy is used due to the routing needed between lemmy/lemmy-ui being handled in nginx. Your reverse proxy can then point to the nginx instance to expose lemmy.

Here is a way to get working Mastodon working behind a reverse proxy that exists on a different machine. Basically, the NGINX server running on the Mastodon instance is configured to “lie” to the the streaming and web servers that the connection is happening over. This way you handle the SSL termination at the actual proxy server. So what you do is change the listen line to 80 and comment out all of the SSL related stuff. Then look for the @proxy section of the NGINX daemon running on the mastodon instance and change the X-Forwarded-Proto header to https as shown below.

server {
  #listen 443 ssl http2;
  #listen [::]:443 ssl http2;
  
  listen 80;
  server_name example.com;

  #ssl_protocols TLSv1.2 TLSv1.3;
  #ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
  #ssl_prefer_server_ciphers on;
  #ssl_session_cache shared:SSL:10m;
  #ssl_session_tickets off;

  # Uncomment these lines once you acquire a certificate:
  #ssl_certificate     /etc/ssl/fullchain.pem;
  #ssl_certificate_key /etc/ssl/private/privkey.pem;

...

location @proxy {
    proxy_set_header Host $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;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://backend;
    proxy_buffering on;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    proxy_cache CACHE;
    proxy_cache_valid 200 7d;
    proxy_cache_valid 410 24h;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    add_header X-Cached $upstream_cache_status;

    tcp_nodelay on;
  }

If you have not yet created the reverse proxy server itself, check out NGINX Proxy Manager as it makes things stupidly easy. NGINX Proxy Manager runs in a dockerized container and makes setting up Let’s Encrypt certs a breeze. Just be sure that when you define the

Mastodon is not hard to get working behind a reverse proxy. I’m about to go to sleep, but when I wake up, I’ll share my configs.

You can point your frontend reverse proxy to the docker reverse proxy.

Think of the NGINX proxy in Lemmy’s docker-compose.yml file as the entry point to Lemmy from outside the Docker network. For instance, I don’t have any ports mapped for the individual services except for the NGINX service. The NGINX proxy in this docker-compose file will access the other services through the internal docker network, so it isn’t a problem if you set up your nginx.conf file with the service’s names. With that done, you could map any port you want for the NGINX service from the host, then point your internet-facing reverse proxy to that.

I also plan on setting up a Mastodon server, but I haven’t gotten to it yet. So I don’t have anything specific to add other than it will work similarly by using docker’s port mapping or service names depending on whether each service needs to be internet-facing or only communicate internally.

Take a look at the Ansible playbook for Lemmy as it Does exactly this. Installing one Nginx on the host system and using one in docker. You can probably pull configuration examples from it.

Depends a lot on your existing reverse proxy.

You can read the nginx config that the defaults include and it’s some basic rules to route incoming requests to either lemmy or lemmy-ui. If your existing reverse proxy is nginx you could just incorporate the rules in there.

It also depends on why you need it behind the existing proxy, and how you’ll choose to route your traffic, and where you traffic is coming from in general.

I’d start with taking a look at the default nginx config to see if you can move those rules to your existing reverse proxy, or just forward everything coming in that’s for lemmy straight to the lemmy reverse proxy, although that might be more complicated in correctly preserving the incoming requests.