Unparseable or unreachable OpenAPI definition blocks Swagger UI operation rendering

We deploy Swagger UI as static files behind a reverse proxy that serves the application from a subdirectory. The UI loads, but instead of listing operations it displays a fetch or parse failure for the API definition. Relative spec paths resolve against the page URL, so a subdirectory deployment can request the wrong document, and a malformed or partially converted OpenAPI file can fail parsing before any operation appears.

The unresolved choice is whether to pin an exact Swagger UI asset version or track a rolling release. Pinning keeps rendering and validation reproducible, while rolling builds can change default validation, deep-linking, and Try-it-out behavior without application code changes. We need to know which approach avoids environment-specific rendering failures when the same build is promoted across base paths.

Should the deployment pin a specific Swagger UI version to stabilize spec fetching and parsing behavior, or is tracking the latest release acceptable when the UI is served from varying subdirectory paths? What verification confirms that the browser is requesting the intended spec URL before promoting the build? Does a documented configuration pattern exist that prevents base-path resolution differences between OpenAPI 2 and 3 documents from causing silent Try-it-out mismatches?