在反向代理后面呈现绝对 URL 的正确方法是什么？

Question

我有一个 web 应用程序在同一台服务器（在myserver.example:80上）的反向代理后面的服务器（假设在localhost:8000上）运行。 由于反向代理的工作方式，应用程序会看到针对localhost:8000的传入请求，因此我使用的框架会尝试生成看起来像localhost:8000/some/ressource而不是myserver.example/some/ressource的绝对 URL myserver.example/some/ressource 。

从这样的代理服务器后面生成绝对 URL （即确定要使用的主机名）的“正确方法”是什么？ 特定的代理服务器、框架和语言无关紧要，我的意思更多的是 HTTP 意义上的。

---

根据我最初的研究：

• RFC7230 明确表示代理必须在传递请求时更改Host header 以使其看起来像请求来自它们，因此看起来像是使用Host来确定用于 URL 的主机名，但在我拥有的大多数地方看起来，一般建议似乎是配置您的反向代理，以便在传递请求时不更改Host header（与规范相反）。
• RFC7230 还说“请求 URI 重建”应该使用以下字段来查找要使用的“权限组件”，尽管这似乎也只适用于发出该请求的代理的角度，例如代理：
• 修复了来自服务器或出站网关配置的 URI 权限组件
• 请求第一行中的权限组件（如果它是完整的 URI 而不是路径）
• 主机 header 如果存在且不为空
• 侦听地址或主机名，以及传入端口号（如果它不是协议的默认端口号）
• HTTP 1.0 didn't have a Host header at all, and that header was added for routing purposes, not for URL authority resolution.
• 有些 headers 是专门为让代理在路由后发送Host的旧值而设计的，例如Via 、 Forwarded和非官方的X-Forwarded-Host ，一些服务器和框架会检查，但不是全部，不清楚是哪个考虑到其中有 3 个，甚至应该优先考虑。

编辑：我也不知道 HTTPS 在这方面是否会有所不同，因为标头是加密有效负载的一部分，因此必须以另一种方式执行路由。

Answer 1

一般来说，我发现最好在应用程序中明确设置真实的主机和端口，而不是尝试从传入的请求中猜测这些。

例如， Jira 允许您设置访问 Jira 的 Base URL （这可能与实际运行的不同）。 这意味着您可以让 Jira 在端口 8080 上运行，并在端口 80 和 443 上（在相同甚至不同的服务器上）在其前面安装 Apache 或 Nginx。