Bitbucket Server context-path configuration when reverse proxy strips path prefix

Goal

Configure Bitbucket Server or Data Center behind a reverse proxy that removes the context-path prefix (e.g., maps /bitbucket/* to /*) so that HTTP clone URLs, REST endpoints, and static resources resolve correctly.

Constraints and uncertainty

• The official reverse proxy guide requires setting server.context-path but does not specify whether the value should match the external URL path (e.g., /bitbucket) or the internal path seen by the application (e.g., /).
• Bitbucket does not automatically honor the X-Forwarded-Prefix header (standard in Spring Boot 2.3+), so the application cannot detect the original prefix from the proxy.
• HTTP clone URLs include the configured context-path, while SSH clone URLs never include a context-path, creating inconsistency when moving from a local development setup (no context-path) to production (with context-path).
• In Data Center deployments, load balancer health checks often target the root path /, which may fail if server.context-path is set to a non-root value.
• Behavior may differ between Bitbucket 7.x (Spring Boot 2.3) and 8.x (Spring Boot 2.7) regarding header forwarding support.

Questions

1. When the reverse proxy strips the context-path prefix, should server.context-path be set to the external path (e.g., /bitbucket) or the internal path (e.g., /)?
2. Is there a version-specific workaround to make Bitbucket respect the X-Forwarded-Prefix header for automatic context-path detection?
3. How should the base URL and health check endpoints be configured to avoid redirect loops and health check failures in a clustered deployment?