[static,spa] unable to serve some routes while trying to run in production mode

[Neah-Ko]

Hello,

I've been developing my first project with sveltekit for the past months. It is now close to completion stage and I am trying to run it in production. It is a Single Page App, hence using adapter static and ssr=False. While I've originally felt I only needed svelte, for this purpose I've hopped onto kit mid-development for routing features.

According to the documentation and relevant examples online, I've set my svelte config like this:

svelte.config.js

import adapter from '@sveltejs/adapter-static';
import { vitePreprocess } from '@sveltejs/vite-plugin-svelte';

/** @type {import('@sveltejs/kit').Config} */
const config = {
	// Consult https://svelte.dev/docs/kit/integrations
	// for more information about preprocessors
	preprocess: vitePreprocess(),

	kit: {
		adapter: adapter({
			fallback: 'index.html',
			pages: 'build',
			assets: 'build',
		}),
		alias: {
			'client': './src/client',
			'auth': './src/auth.ts',
			'tsconfig': './openapi-ts.config.ts'
		},
		prerender: {
			entries: [
				'/',
				'/about',
				'/login',
				'/logout',
                                '...', # some more routes
				'/[...404]'
			],
		},
	}
};

export default config;

Then building is straightforward

npm run build

If I check the result with some node based solutions, this will work as expected i.e.

npm run preview

or

docker run -v /path/to/client/build:/opt/www -p 5001:8080 webratio/nodejs-http-server:latest

I can play around with the website, and it works just as in development mode.

The problem arises when I'm trying to use a lighter solution, closer to the target environment such as:

nginx

FROM nginx:alpine

ADD --chown=root:root ./build /usr/share/nginx/html
COPY nginx.conf /etc/nginx/conf.d/

RUN chmod -R 755 /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

# nginx.conf
server {
    listen 80;
    server_name localhost;
    root /usr/share/nginx/html/;

    location ~ ^/200\.html$ { }

    location / {
        if (!-e $request_filename){
            rewrite ^(.*)$ /200.html break;
        }

        if ($request_uri ~ ^/(.*)\.html(\?|$)) {
            return 302 /$1;
        }

        try_files $uri $uri/ $uri.html /index.html;
        index index.html;
    }

    location ~ \.html$ {
        add_header Cache-Control "no-cache, no-store, must-revalidate";
        expires -1;
    }

    location ~ \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf)$ {
        expires 1y;
        add_header Cache-Control "public";
    }
}

then

docker build . -t client:test
docker run -p 5001:80 client:test

the login page (which has nothing to display, it is just there to redirect after external authentication) becomes inaccessible. Throwing those kind of errors:

172.17.0.1 - - [21/Mar/2025:11:24:19 +0000] "GET /login?state=&session_state=de6f96c5-8dea-48ae-a2fd-38b25f0cde4f&code=98e78b1b-7977-4eca-8b25-10459f6750ea.de6f96c5-8dea-48ae-a2fd-38b25f0cde4f.1154ee7d-40bb-4024-9e51-eadc03d0db54 HTTP/1.1" 404 555 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36" "-"
2025/03/21 11:24:19 [error] 31#31: *2 open() "/usr/share/nginx/html/login" failed (2: No such file or directory)

while login.html is well present in that build/ folder.

A lot of that nginx.conf file are unsuccessful attempts to address the issue, I'm not an expert with it either.

Lastly, I've also tried with

cd build/
python -m http.server 5001 

Which yields results on par with nginx producing 404 on attempts at accessing /login.

Interestingly, that login loop stores an access token in the local storage. So If I run it first with any working solution such as npm run preview then turn it off and switch to nginx, the rest of the application seem to be perfectly usable while that token is valid.

Ultimately, I would like to know where to look at in order to know what configuration nodejs-http-server (and vite I suppose ?) is doing to support that routing wich nginx/python-http-server are not doing natively, and If anyone could help it would be much appreciated.

Since that login feature is directing the user to another website to be redirected back with a valid access token on success, would it have to do with upstream configuration ?

Best,