Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@uvicorn/config.py` around lines 306 - 308, Update Config initialization to
reject configurations where both root_path and asgi_root_path are set, rather
than only logging and continuing. Raise the established configuration error from
the validation branch so direct Config consumers cannot run with conflicting
path values, and add coverage for direct Config construction with both options.

Learnt from: amol-
Repo: Kludex/uvicorn PR: 2493
File: uvicorn/config.py:306-308
Timestamp: 2026-08-05T09:57:28.788Z
Learning: In Uvicorn, `Config.__init__` reports invalid configuration combinations by logging instead of raising. Command entry points such as `uvicorn.main.run()` perform hard failure with `sys.exit(STARTUP_FAILURE)` after configuration construction. Existing examples include reload-related configuration validation.

Check if this issue is valid — if so, understand the root cause and fix it. At uvicorn/config.py, line 225:

<comment>Existing positional `uvicorn.Config` callers can silently configure the wrong limits, timeouts, or SSL settings because this new optional parameter was inserted before existing parameters. Appending `asgi_root_path` after the current parameter list would preserve the public constructor’s positional compatibility.</comment>

<file context>
@@ -222,6 +222,7 @@ def __init__(
         date_header: bool = True,
         forwarded_allow_ips: list[str] | str | None = None,
         root_path: str = "",
+        asgi_root_path: str = "",
         limit_concurrency: int | None = None,
         limit_max_requests: int | None = None,
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At uvicorn/config.py, line 307:

<comment>The mutual-exclusion check only logs an error and is only enforced in `uvicorn.run()` via `sys.exit(1)`. When someone uses the programmatic API `uvicorn.Server(uvicorn.Config(..., root_path=..., asgi_root_path=...))` — the documented way to embed the server — the invalid combination isn't rejected: the config logs an error and then keeps serving, and because of `self.asgi_root_path = asgi_root_path or root_path` the `asgi_root_path` value arbitrarily wins. That clashes with the PR's goal of rejecting simultaneous use and with the settings doc calling them mutually exclusive. Consider raising a `ValueError` from `Config.__init__` when both are set, which would make the rejection consistent across CLI and programmatic use and let `run()` drop its duplicated `sys.exit` branch.</comment>

<file context>
@@ -301,6 +303,9 @@ def __init__(
         self.reload_excludes: list[str] = []
 
+        if root_path and asgi_root_path:
+            logger.error("Setting both 'root_path' and 'asgi_root_path' is not supported.")
+
         if (reload_dirs or reload_includes or reload_excludes) and not self.should_reload:
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At docs/deployment/index.md, line 194:

<comment>Consider linking to the canonical `--asgi-root-path` documentation in docs/settings.md instead of re-explaining the option's semantics here, keeping the deployment page concise and pointing to the single source of truth. The nginx example itself is accurate.</comment>

<file context>
@@ -189,6 +189,26 @@ http {
 
+### Subpath deployments
+
+If your proxy serves the application from a subpath and forwards requests without stripping that prefix, use `--asgi-root-path` so ASGI `root_path` is set without duplicating the request path.
+
+For example:
</file context>