Is it possible to use the Sliding Sync server when fronting everything with my own NGINX reverse proxy?

[randomsnowflake]

I'm fronting my matrix setup through my own NGINX, as described here Fronting the integrated reverse-proxy webserver with another reverse-proxy. Matrix itself uses traefik.

It seems this breaks the Sliding Sync server. matrix.MYDOMAIN/sliding-sync yields a 404 (from NGINX). Element X doesn't get past "Setting up your account, this is a onetime process, thanks for waiting"

How can I configure my NGINX to proxy requests to the sliding sync correctly?

[Happyfeet01]

I can’t do that also. I got an 404 error when accessing matrix.domain.tld/sliding-sync

[Avsynthe]

Heya Gents.

I'm working on this. I have it semi-working right now. It's working with SchildiChat just fine it seems but it's not working with Element X. I'm hard at it, however. I'll hopefully have a write-up soon once I get it functioning for both. There's some extra variables we need to use for this to work for us.

Unless you've figured it out already that is, I'd love to see it if so. If not, hold tight.

[Happyfeet01]

Heya Gents.

I'm working on this. I have it semi-working right now. It's working with SchildiChat just fine it seems but it's not working with Element X. I'm hard at it, however. I'll hopefully have a write-up soon once I get it functioning for both. There's some extra variables we need to use for this to work for us.

Unless you've figured it out already that is, I'd love to see it if so. If not, hold tight.

With my setup i got only an spinning Circle at Element at iOS. It seems sliding-sync works.

[Avsynthe]

Heya Gents. I'm working on this. I have it semi-working right now. It's working with SchildiChat just fine it seems but it's not working with Element X. I'm hard at it, however. I'll hopefully have a write-up soon once I get it functioning for both. There's some extra variables we need to use for this to work for us. Unless you've figured it out already that is, I'd love to see it if so. If not, hold tight.

With my setup i got only an spinning Circle at Element at iOS. It seems sliding-sync works.

To address your previous reply, sliding-sync may very well be functioning, but when it's being proxied to correctly by our webservers, we're meant to be getting a 404 error when visiting the URL in a browser, and a 405 error when attempting to visit the endpoints. Though unless you've manually exposed the sliding sync container, this will never happen

[Avsynthe]

Ok guys we finally got there. It took days to figure it out with my limited knowledge and help from ChatGPT roleplaying as my server, with me feeding it the contents of files in the Matrix setup. All this to get a full understanding of how we're meant to mimic the workings of the internal proxy services with our external web servers, and understand why the playbook defaults for sliding sync are not external web-server friendly.

To start off, this is far easier to do when using a different subdomain to your matrix domain. So something other than matrix.yourdomain.com. I have chosen to use sync-matrix.yourdomain.com (yes this can be proxied in Cloudflare). For some reason though, SchildiChat Desktop tested on 2 PC's isn't working correctly with this, though both SchildiChat Web and Element Web do work fine with this Sliding Sync setup. I'm sussing this out now

Also its worth mentioning you do not need to worry about the nginx config examples in the readme at the Sliding Sync repo. That /_matrix/client/unstable/org.matrix.msc3575/sync path you're seeing is actually the internal path the Sliding Sync service/docker container uses to listen on (the endpoint). What you're seeing in their examples is their recommendation to use the same path in your proxy for external use when using the same domain purely for consistency.

Similarly, the /sliding-sync path you've seen in the ansible playbook's docs is actually REPLACING this as it's just a shorter, simpler path. We won't be worrying about either of these paths as we're using a different subdomain and passing ALL traffic through. We won't need any path.

Here are the variables we need to use in vars.yml:

# Enables the Sliding Sync proxy
matrix_sliding_sync_enabled: true

# Maps a port on the host, passed into the Sliding Sync container's internal listening port. MUST be set as by default the container has no host bindings and thus can never be reached from outside the internal docker network. Not even locally. I have chosen host port 8018 so that it's well out of the way
matrix_sliding_sync_container_extra_arguments:
  - "-p 8018:8008"

# Sets the server URL the server tells clients to try to connect to it with. This should be your https://matrix.yourdomain.com URL, including the "https://". MUST be set as for some reason the default tells clients to use an internal docker hostname, namely matrix-nginx-proxy container which obviously won't work externally and caused 404's in the sliding sync logs.
matrix_sliding_sync_environment_variable_syncv3_server: "https://matrix.yourdomain.com"

Ok now on to our Nginx Proxy Manager setup:

Your advanced config for your matrix.yourdomain.com (and potentially a portion of your config for your base domain yourdomain.com) proxy should look like this if this is how you're serving your well-known json files. This is FAR easier than figuring out how to mount and serve the files from the server. You're writing the json yourself here and can edit any time:

location /.well-known/matrix/client {
    return 200 '{
    "m.homeserver": {
        "base_url": "https://matrix.yourdomain.com"
    },
    "org.matrix.msc3575.proxy": {
        "url": "https://sync-matrix.yourdomain.com"
    }
}'; 
    default_type application/json;
    add_header Access-Control-Allow-Origin *;
}

Now for your sync-matrix.yourdomain.com URL, make a host for that in Nginx Proxy Manager and point it to YourMatrixServerIP:8018

And that's it! This may not be the perfect way to do it or even the way it's meant to be done (if there is a way set by the playbook), but this definitely works at least for Element X and the Element Web and SchildiChat Web clients. As I said, I'm still working out the kinks with SchildiChat Desktop and will alter the write-up if needed.

I read in the matrix support room for the ansible deploy that we who manage our own external webservers are apparently the vast minority. That is honestly crazy to me and makes me sad! But if it's the case, that's why there's less support and less people answering our questions in there amidst the massive volume of messages per day.

[Happyfeet01]

@Avsynthe i tried your setup, Element X on iOS has no connection

[gitayam]

Not an option with Element X apparently. https://areweoidcyet.com/

[theCalcaholic]

I finally managed to configure nginx to reverse proxy the sliding-sync proxy correctly on the same domain (for whatever reason it doesn't seem to work through traefik):

Add the following block in your nginx reverse proxy config (assuming you're using the default path for the sliding sync proxy):

location /sliding-sync {
    resolver 127.0.0.11 valid=5s;
    set $backend "matrix-sliding-sync:8008";
    rewrite ^/sliding-sync(/.*)$ $1 break;
    proxy_pass http://$backend;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}