Skip to content

Knowledgebase

Configuring FastAPI root paths and proxy headers

development

A proxy can publish an API below a path such as /api while forwarding a shorter path internally. Correct root-path and trusted-header configuration keeps redirects and API documentation consistent.

Check access and requirements

Document the external URL, the path the proxy removes or retains and the internal listener. Confirm which clients are allowed to connect directly to that listener.

01 Configure FastAPI root paths and proxy headers

  1. Test the actual upstream path received by the application. Decide whether the proxy strips the public prefix or forwards it unchanged.

  2. Configure the ASGI root_path for the intended deployment when a stripped public prefix must be represented. Avoid adding the same prefix independently in several layers.

  3. Trust forwarded headers only from the actual proxy sources. A wildcard trust setting is appropriate only when network access reliably limits all direct requests to trusted proxies.

  4. Check application-generated redirects and the OpenAPI server URL. Configure any intentional additional server entries through the application settings.

  5. Restart the service and test both a normal endpoint and documentation loaded through the public prefix.

02 Example: publish FastAPI under a stripped /api prefix

Assume the public proxy accepts /api/status and forwards /status to the application. In that specific arrangement, the app should know its external mounting prefix without adding the prefix again to every route.

Code or configuration example
from fastapi import FastAPI

app = FastAPI(root_path='/api')

@app.get('/status')
def status():
    return {'status': 'ok'}

The browser-facing endpoint is https://example.com/api/status. If the proxy instead forwards the full /api/status path, correct the routing design rather than assuming root_path rewrites it. Configure trusted forwarded headers only for the actual proxy addresses and the service’s supported listener arrangement.

Expected result: The public endpoint and, where enabled, /api/docs both use the same HTTPS prefix. Requests generated by the documentation do not omit /api or accidentally call /api/api/status.

Confirm the expected result

Confirm browser requests remain on the correct HTTPS hostname and path. An endpoint working internally is insufficient if generated public URLs omit or duplicate the prefix.

Resolve setup problems

A documentation page that loads but cannot call the API often points to a wrong server URL or root path. Compare its outgoing request with the proxy route.

A common question

Does root_path rewrite every incoming request?

It describes the mounting context to the ASGI application. The reverse proxy and route configuration still need to forward the intended path correctly.

Sources and further reading

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support

Powered by WHMCompleteSolution