Host in a subpath/subfolder

[adrez99]

Hi, I saw that aMule got updated recently and have been testing it with great results. And now I've found aMuTorrent which is great, good work!

I currently host qbittorrent and mldonkey reverse proxied with swag (nginx), but would like to unify them with aMuTorrent. In order to do that I need to host aMuTorrent in a subpath (can't create a subdomain).
I've read the docs but haven't found anything, and I've tried different configs in nginx but it seems some resources are absolute paths (/static/dist/app.bundle.js).

I'd like to know if it's possible, and the nginx config to do it.
If it's not, this is a feature request to allow it.
Thanks!

[got3nks]

Hi @adrez99, thanks for the kind words.

You're right that some asset paths are absolute (/static/..., /api/..., the WebSocket URL) — aMuTorrent doesn't currently have first-class subpath support, all front-end resources and API calls root at /. So a plain location /amutorrent/ { proxy_pass ... } won't work.

It is, however, achievable with nginx by using sub_filter to rewrite responses on the fly. Working config (paste into your SWAG site config):

location ^~ /amutorrent/ {                     # ^~ stops nginx falling through to regex locations
    rewrite ^/amutorrent/(.*) /$1 break;       # explicit prefix strip — robust across nginx layouts
    proxy_pass http://amutorrent:4000;
    proxy_http_version 1.1;
    proxy_set_header Host              $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header Upgrade           $http_upgrade;
    proxy_set_header Connection        "upgrade";
    proxy_set_header Accept-Encoding   "";     # let sub_filter see plain text

    # long timeouts so the WebSocket isn't dropped after the default 60s of idle
    proxy_read_timeout 86400;
    proxy_send_timeout 86400;

    sub_filter '/static/'  '/amutorrent/static/';
    sub_filter '/api/'     '/amutorrent/api/';
    sub_filter '/indexer/' '/amutorrent/indexer/';
    sub_filter '/ws`'      '/amutorrent/ws`';    # WS URL is in a template literal
    sub_filter '"/ws"'     '"/amutorrent/ws"';   # quoted form (defensive)
    sub_filter "'/ws'"     "'/amutorrent/ws'";   # quoted form (defensive)
    sub_filter_once off;
    sub_filter_types text/html text/css application/javascript;
}

Key points to watch if it's still flaky:

• location ^~ /amutorrent/ (the ^~ modifier) tells nginx "match this prefix and don't try regex locations." Without it, SWAG's base config (which has plenty of regex location ~ \.(ext)$ rules for security headers / file types) can intercept /amutorrent/static/foo.css before our block's sub_filter runs.
• The /ws rule has to match the backtick (`/ws`), not just "/ws". In the minified bundle the WebSocket URL is built as a template literal — `${protocol}//${host}/ws` — so the literal /ws is followed by a backtick, not a quote. Without that rule the page loads fine but the WS connection dies (browser tries wss://yourhost/ws at the root and nginx 404s it).
• rewrite ^/amutorrent/(.*) /$1 break; is the explicit prefix-strip. Some nginx layouts (SWAG / regex-heavy server blocks) need it instead of relying on proxy_pass http://upstream/ to strip the location prefix.
• proxy_read_timeout 86400; keeps idle WebSockets alive — without it nginx closes the connection after 60s of silence.

A proper "subpath-native" mode (the app reading a configured base path from server.basePath, injecting <base href="...">, relative fetches/WS URLs) is a reasonable feature ask — I'll leave this issue open as a tracking item for that. The sub_filter workaround works but it's clearly fragile (the /ws template-literal case being a good example), so a proper fix is worth doing eventually. Let me know if the updated snippet gets WS working for you.

[adrez99]

I've tried the config but doesn't work, but after I added rewrite ^/amutorrent/(.*) /$1 break; it started showing something.
It seems the websocket connection is failing, but don't know how to workaround it. Any clue?

Thank you for looking at it!

[got3nks]

@adrez99 you found the right gap — sorry about that. Two issues with the original config:

1. The explicit rewrite ^/amutorrent/(.*) /$1 break; you added was correct. Some nginx layouts (SWAG / regex-heavy server blocks) don't reliably strip the location prefix via proxy_pass http://upstream/ alone. Good catch.

2. The WebSocket failure is on my end. The original sub_filter '/ws' rules targeted "/ws" and '/ws' (quoted strings) — but in the minified bundle the WebSocket URL is built with a template literal, not a quoted string:

   `${protocol}//${window.location.host}/ws`

   So in the bundle /ws appears as …host}/ws` (followed by a backtick). My rules didn't match it, the browser never got the prefix, and the connection went to wss://yourhost/ws at nginx's root — 404.

I've edited the top comment above with the corrected config. The key additions:

sub_filter '/ws`'    '/amutorrent/ws`';   # ← template literal — this is what actually matters
proxy_read_timeout   86400;                # ← long idle timeout for WS
proxy_send_timeout   86400;

Plus your rewrite line is now in the snippet by default. Give it another try and let me know — should bring the WebSocket up.

[adrez99]

I added the last sub_filter and the connecting message disappeared but wasn't working very well, then I changed location ^~ /amutorrent/ and it started working perfectly!
Everything I tested is fully functional, so I think this workaround makes the proper fix have a lower priority.
Thank you so much!

[got3nks]

@adrez99 great — glad it's working end-to-end. The ^~ modifier was the missing piece, thanks for digging it out. Without it, SWAG's regex location blocks (security headers, file-type rules) intercept paths like /amutorrent/static/foo.css before our prefix block's sub_filter runs. With ^~ the prefix wins outright.

I've folded the ^~ into the top comment so future readers get the complete working config in one paste.

Fair call on deprioritizing native subpath support given the workaround is stable. I'll leave this issue open as a tracking item rather than closing it — that way if more users hit this we'll see the demand and can decide to do the proper refactor (configurable server.basePath, relative fetch/WS URLs, <base href> injection). For now your config is the documented path. Thanks for sticking with it through the iterations.