(Apologies in advance if this is the wrong spot to ask for help, and/or if the length annoys people.)

I'm trying to set up 2FAuth on a local server (old Raspberry Pi, Debian), alongside some other services.

Following the self-hosting directions, I believe that I managed to get the code running, and I can get at the page, but can't register the first/administrative/only account. Presumably, something went wrong in either the configuration or the reverse-proxy, and I've run out of ideas, so could use an extra pair of eyes on it, if somebody has the experience.

The goal is to serve it from http://the-server.local/2fa, where I have a...actually the real name of the server is worse. Currently, the pages (login, security device, about, reset password, register) load, but when I try to register an account, it shows a "Resource not found / 404" ("Item" in the title) page.

Here's the (lightly redacted) .env file, mostly just the defaults.

APP_NAME=2FAuth
APP_ENV=local
APP_TIMEZONE=UTC
APP_DEBUG=false
SITE_OWNER=mail@example.com
APP_KEY=base64:...
APP_URL=http://the-server.local/2fa
APP_SUBDIRECTORY=2fa
IS_DEMO_APP=false
LOG_CHANNEL=daily
LOG_LEVEL=notice
CACHE_DRIVER=file
SESSION_DRIVER=file
DB_CONNECTION=sqlite
DB_DATABASE=/var/www/2fauth/database/database.sqlite
DB_HOST=
DB_PORT=
DB_USERNAME=
DB_PASSWORD=
MYSQL_ATTR_SSL_CA=
MAIL_MAILER=log
MAIL_HOST=my-vps.example
MAIL_PORT=25
MAIL_USERNAME=null
MAIL_PASSWORD=null
MAIL_ENCRYPTION=null
MAIL_FROM_NAME=2FAuth
MAIL_FROM_ADDRESS=2fa@my-vps.example
MAIL_VERIFY_SSL_PEER=true
THROTTLE_API=60
LOGIN_THROTTLE=5
AUTHENTICATION_GUARD=web-guard
AUTHENTICATION_LOG_RETENTION=365
AUTH_PROXY_HEADER_FOR_USER=null
AUTH_PROXY_HEADER_FOR_EMAIL=null
PROXY_LOGOUT_URL=null
WEBAUTHN_NAME=2FAuth
WEBAUTHN_ID=null
WEBAUTHN_USER_VERIFICATION=preferred
TRUSTED_PROXIES=null
PROXY_FOR_OUTGOING_REQUESTS=null
CONTENT_SECURITY_POLICY=true
BROADCAST_DRIVER=log
QUEUE_DRIVER=sync
REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379
PUSHER_APP_ID=
PUSHER_APP_KEY=
PUSHER_APP_SECRET=
PUSHER_APP_CLUSTER=mt1
VITE_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
VITE_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"
MIX_ENV=local

Then, there's the hard-won progress on the NGINX configuration.

server {
    listen 80;
    server_name the-server.local;
# Other services
    location /2fa/ {
        alias /var/www/2fauth/public/;
        index index.php;
        try_files $uri $uri/ /index.php?$query_string;
    }
    location ~ ^/2fa/(.+?\.php)(/.*)?$ {
        alias /var/www/2fauth/public/;
        fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        set $path_info $fastcgi_path_info;
        fastcgi_param PATH_INFO $path_info;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root/$1;
        include fastcgi_params;
    }
# ...and so on

I have tried dozens of variations, here, especially in the fastcgi_param lines, almost all of which either don't impact the situation or give me a 403 or 404 error for the entire app. This version at least shows login/register/about pages.

While I would've loved to do so, I can't work with the documentation's example, unfortunately, because (a) it presumes that I only want to run the one service on the machine, and (b) doesn't seem to work if transposed to a location. They do have the Custom Base URL option, but it doesn't work. That just gives me a 403 error (directory index of "/var/www/2fauth/public/" is forbidden, client: 192.168.1.xxx, server: the-server.local, request: "GET /2fa/ HTTP/1.1", host: "the-server.local", and again I emphasize that the permissions are set correctly) for the entire app, making me think that maybe nobody on the team uses NGINX.

Setting both NGINX and 2FAuth for debugging output, the debug log for NGINX gives me this, of the parts that look relevant.

*70 try files handler
*70 http script var: "/2fa/user"
*70 trying to use file: "user" "/var/www/2fauth/public/user"
*70 http script var: "/2fa/user"
*70 trying to use dir: "user" "/var/www/2fauth/public/user"
*70 http script copy: "/index.php?"
*70 trying to use file: "/index.php?" "/var/www/2fauth/public//index.php?"
*70 internal redirect: "/index.php?"

And the Laravel log is empty, so it's not getting that far.

Permissions and ownership of 2FAuth seem fine. No, there's no /var/www/2fauth/public/user, which seems to make sense, since that's almost certainly an API endpoint and none of the other "pages" have files by those names.

I have theories on what the application needs (probably the path as an argument of some sort), but (a) I'm not in the mood to slog through a PHP application that I don't intend to make changes to, and (b) I don't have nearly the experience with NGINX to know how to make that happen.

It seems impossible that I'm the first one doing this, but this also feels like a small enough problem (especially with a working desktop authenticator app) that it's not worth filing a GitHub issue, especially when their existing NGINX examples are so...worryingly off. So, if anybody can help, I'd appreciate it.

I have no experience with this app in particular, but most of the time there is an issue like this that you can't reach an app or any other path besides the index, is because the app itself doesn't work well with path redirection of subfolders, meaning the app expects paths to be something like domain.tld/index.html instead of domain.tld/subfolder/index.html for all its routes.

Some apps let you add a prefix to all its routes they can work, so you not only have to configure nginx but the app itself to work with the same subfolder.

Other apps will work with the right configuration in nginx if they do a new full page load every time the page changes its path/route.

If it is a PWA that doesn't do a page load every time the path is changed, it's not going to work with subfolders as they don't do any page refresh that goes through nginx, and just rewrite the visible URL on the browser

What I can recommend is to switch to a subdomain like 2fa.domain.tld instead of a subfolder and test if it works, as subdomains are the modern standard for this kind of thing these days, to avoid this type of issues.

Edit: looking at the app demo, it seems to be a vue.js PWA that doesn't do any full page refreshes on a path change, so as stated you will probably have to switch to a subdomain to make it work.