Paths and routing

1. Make a pool for the API servers.
2. Open the site, Paths, Add a path.
3. Path /api, match type Prefix, mode Proxy, and choose the API pool.
4. Leave the strip prefix setting off if the application was written knowing it lives under /api.
5. Save and apply.

As soon as a site has any paths at all, it stops using the single backend on the Basics tab and serves only what is listed under Paths. A request that matches nothing gets nginx's own 404.

Add a path of / pointing at your main pool to catch everything else.

The page was found and its stylesheet was not. It looks like an appearance problem and it is really the path prefix.

Either the application has not been told which prefix it lives under, or the prefix is being stripped when the application expects it, or it is not being stripped when the application does not expect it. Flip the strip setting and try again.

Add a path such as /downloads, set the mode to Static, and give it a folder. Everything else keeps going to the pool. The files have to exist on every node.

Make a rate limit zone on the Zones and Access page, then add a path for /login and choose that zone on the path rather than on the whole site. Everything else is untouched.

nginx does not read them top to bottom. It picks the most specific match. A request for /api/users matches a path of /api rather than the site's general rule, because /api is more specific. You do not have to put them in any particular order.

Set the match type to Regular expression. Use it for things that are genuinely irregular, such as matching a set of file extensions. Prefix matching is what you want almost every other time, and it is faster.

A React, Vue or Angular app handles its own addresses in the browser. Press refresh on /settings/profile and the browser asks the server for a file at that path, which does not exist.

The tidiest answer is to let whatever serves the app do the fallback, because that is a job the app framework already knows how to do. Add a path for /api/ pointing at the API pool, and a path of / pointing at the pool that serves the app. Nothing special is needed here.

If you would rather serve the build straight off the load balancer, set the site to Serve files off the disk with Document root on the build folder. The fallback itself has no box of its own, so put it in Extra config for this path on a path of /. Press Check it on the nginx config tab before you apply, and it is validated on every node.

Either way, serve the built assets folder as a path of its own, so scripts and images are found as files rather than being answered with the index page. That mistake shows up as an app that loads a blank screen and a console full of unexpected token errors.

Add the path, choose Send it to a pool, and tick Serve a whole website here.

That box tells the load balancer the thing on the other end is a website in its own right, not a piece of yours. Redirects and cookies coming back get their paths corrected so the visitor stays under your path instead of being thrown out to the root.

Without it, a sign in on the embedded site sends the visitor to /login at the top of your domain and everything falls apart at the first click.

Add the path and set What happens to Refuse it. The request never reaches your application.

Useful for an admin endpoint that should never be reachable from outside, an old API version you have retired, or a folder a scanner keeps asking for.

If you want it reachable from the office only, use Who may reach this path with an access list instead. Refusing is for things nobody should get.

Edit the path and tick Settings for this path only. The whole Settings tab opens up for that path alone, and anything you leave alone keeps following the site.

This is how nearly every real site ends up configured. A long timeout on the reports path and a short one everywhere else. Caching on the assets path and nothing anywhere else. A rate limit on the login and none on the rest.

Set up the path to serve files from disk, then open the site, Settings tab, Static Files, and tick Directory listing. Pretty directory listing gives readable sizes and local times instead of the bare version.

Do it as a path with Settings for this path only, not on the whole site. Turning on directory listing everywhere means any folder without an index file becomes a browsable list of what is in it, which is rarely what anybody meant.

Add a path for the health address, tick Settings for this path only, and untick Access log so it stops filling the log.

If the checker needs a fixed body rather than just a status, put the response in Extra config for this path on the same dialog. The nginx config tab shows the result before you apply, and Check it validates it on every node.

Worth knowing: your own uptime monitor should be checking a path that really touches the application, not one the load balancer answers on its own. A health endpoint that always says yes is a monitor that never tells you anything.