How to Enable Advanced Configuration for Matrix .well-known Paths in Zoraxy?

[gabriellxxix]

Hi everyone,

I’ve been working on setting up .well-known verification for my Matrix server, and I ran into some challenges when attempting to use a static web server like Zoraxy. My goal was to serve the .well-known/matrix paths with proper responses. Here’s a breakdown of my experience and a working solution I found using Nginx Proxy Manager (NPM):

The Issue with Zoraxy
Initially, I configured Zoraxy to handle .well-known/matrix/server and .well-known/matrix/client paths through virtual directories. While the server endpoint worked correctly, returning the expected JSON response, the client endpoint consistently failed with an error:

{"errcode":"M_NOT_FOUND","error":".well-known not available"}g

Despite extensive configuration attempts and research, I couldn’t find a way to make Zoraxy handle the client endpoint reliably. It seems Zoraxy lacks an easy mechanism for advanced custom responses (e.g., specific JSON payloads) under its current architecture.

Working Solution Using NPM
After switching to Nginx Proxy Manager, I managed to achieve the desired setup with the following configuration added under the Advanced tab for the proxy host (as shown in the attached screenshot):

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}, "m.identity_server": {"base_url": "https://vector.im"}}';
}

This configuration serves the appropriate JSON responses for both the server and client endpoints, allowing .well-known verification to pass successfully. The setup process in NPM was straightforward and flexible for adding custom configurations like these.

Proposed Feature Suggestion for Zoraxy
Given this experience, I’d like to suggest a feature improvement for Zoraxy to include advanced configuration support, similar to what NPM offers in its Advanced tab. For instance, a feature that allows users to directly specify custom locations and define JSON responses or headers would greatly enhance Zoraxy’s usability for scenarios like .well-known verification.

Remaining Questions
Although I resolved my issue by using NPM, I’m curious if anyone here has successfully set up .well-known verification using Zoraxy. Specifically:

Are there alternative methods or plugins that enable advanced configurations in Zoraxy?
Have I overlooked an existing way to achieve this setup within Zoraxy’s capabilities?
I’d love to hear your thoughts or experiences on this topic! Any insights would be greatly appreciated.

Thank you in advance for your advice and suggestions!

[overcuriousity]

i would also hope for a solution for this.

[tobychui]

Due to the limitation of the current architecture, it is clear that this feature belongs to the plugin category. That is why I am proposing a new plugin infrastructure design but sadly no one wanna contribute any ideas on that yet.

[overcuriousity]

Your plugin system looks like a great idea IMO although I lack the imagination of what could be done with this. Especially the containerization is interesting, although I don´t know how scalable it would be.
I will definitely give it a thought and contribute if I can make something up.

However, i don´t see how this would solve the problem described in this thread, as we would just need an additional "Advanced Setting" in the virtual directories where we could set a return value for the location blocks, exactly as it is handled in nginx - as seen in the OP.
I think this would be a valuable Iteration as at least Matrix requires such a configuration, which is a significantly popular application on home servers, the same scope where zoraxy is as i can see.

[tobychui]

Sorry for skipping straight to the point and missed all the explanation. I am really busy recently.

The .well-known cannot be easily reverse proxy via subdomain or vdir as it is captured and handled by the "Special Routing Rule" which the ACME module register. It IS possible to add an advance setting in vdir just to handle this special case (e.g. .well-known/matrix/*) but then it will become an issue to me (and other maintainer) if other applications that uses similar paths, for example .well-known/myapp/* also request such "special settings" in Zoraxy. Then I can foresee what happens next will be adding more and more special settings and eventually that special setting toggle / checkbox will become an generic input field. That will just make beginner users more confused about what to fill in. (And yes, I am well aware of the ACME modules have tons of generic input fields that make users lose their way setting it up. I admit it is a really bad design in terms of "ease of use" but currently I do not have that much spare time to rework it)

The better way to do it, in terms of the code architecture and maintenance standpoint, would be move such implementations to plugin. That way, it (the special features required by a particular sets of open source software / ecosystem ) can be owned and developed by 3rd party developers, preferably provided by the open source project that request them in the first place. Just like how other open source project provide example nginx / apache reverse proxy settings snippet.

So to summarize, the reason why I am not implementing this now is not because of technical but architectural reasons. This have to wait until plugin modules is finish (and preferably entered beta phase) before any work can continue.

[overcuriousity]

Okay I think I understand a bit better, but its hard to wrap your head around zoraxy when you only knew nginx before...

Plugins are for adding flexibility without adding complexity out of the box, basically.
I am a fan of this concept and will be looking forward for when its done!

Sadly can´t contribute as a Python guy...
Keep up the great work 👍

[overcuriousity]

Hi everyone,

I’ve been working on setting up .well-known verification for my Matrix server, and I ran into some challenges when attempting to use a static web server like Zoraxy. My goal was to serve the .well-known/matrix paths with proper responses. Here’s a breakdown of my experience and a working solution I found using Nginx Proxy Manager (NPM):

The Issue with Zoraxy Initially, I configured Zoraxy to handle .well-known/matrix/server and .well-known/matrix/client paths through virtual directories. While the server endpoint worked correctly, returning the expected JSON response, the client endpoint consistently failed with an error:

{"errcode":"M_NOT_FOUND","error":".well-known not available"}g

Despite extensive configuration attempts and research, I couldn’t find a way to make Zoraxy handle the client endpoint reliably. It seems Zoraxy lacks an easy mechanism for advanced custom responses (e.g., specific JSON payloads) under its current architecture.

Working Solution Using NPM After switching to Nginx Proxy Manager, I managed to achieve the desired setup with the following configuration added under the Advanced tab for the proxy host (as shown in the attached screenshot):

location /.well-known/matrix/server {
    default_type application/json;
    return 200 '{"m.server": "matrix.example.com:443"}';
}

location /.well-known/matrix/client {
    default_type application/json;
    return 200 '{"m.homeserver": {"base_url": "https://matrix.example.com"}, "m.identity_server": {"base_url": "https://vector.im"}}';
}

This configuration serves the appropriate JSON responses for both the server and client endpoints, allowing .well-known verification to pass successfully. The setup process in NPM was straightforward and flexible for adding custom configurations like these.

Proposed Feature Suggestion for Zoraxy Given this experience, I’d like to suggest a feature improvement for Zoraxy to include advanced configuration support, similar to what NPM offers in its Advanced tab. For instance, a feature that allows users to directly specify custom locations and define JSON responses or headers would greatly enhance Zoraxy’s usability for scenarios like .well-known verification.

Remaining Questions Although I resolved my issue by using NPM, I’m curious if anyone here has successfully set up .well-known verification using Zoraxy. Specifically:

Are there alternative methods or plugins that enable advanced configurations in Zoraxy? Have I overlooked an existing way to achieve this setup within Zoraxy’s capabilities? I’d love to hear your thoughts or experiences on this topic! Any insights would be greatly appreciated.

Thank you in advance for your advice and suggestions!

As a reply to the OP, I found an easy workaround for the time being, which might not be perfect:

1. Install NGINX locally on the matrix Container/VM
2. configure matrix to run on 127.0.0.1:8443 (or whatever) with the location blocks
3. expose nginx on port 80 or whatever (choose if you want to do SSL termination or not - not using SSL behind zoraxy might of course imply that an attacker which gains access to your network is able to collect unencrypted traffic)
4. configure zoraxy with your URL (SSL mandatory, of course) and forward traffic to the nginx endpoint locally configured)

This seems a bit redundant, of course, but in my example case was necessary as all my infrastructure is depending on zoraxy at the moment and the matrix container has to make compromises.

[bstone108]

You could also create your well known file in the static web server part of zoraxy, then use a virtual directory to point at the folder you have your file located in. So whatever.com/.well-known points at the static virtual directory. add a folder to the static server named .well-known/matrix and put your file there. I'm not positive this would work, don't have time to test it. But it should allow the proxy to serve your well-known files for your root domain.