在Java Web开发中，准确获取请求域名是构建动态链接、配置跨域资源共享（CORS）以及实现多租户系统的基础功能，在实际的生产环境中，由于反向代理（如Nginx）、负载均衡以及SSL卸载等架构的存在，直接使用标准API往往无法获取到用户浏览器中真实的访问域名。核心上文归纳是：要准确获取请求域名，必须优先检查代理服务器传递的专用请求头（如X-Forwarded-Host），并结合协议（Http/Https）与端口信息，构建一个兼容直连与代理环境的通用获取逻辑，同时需警惕Host Header注入攻击的安全风险。
基础API与标准获取方式的局限性
在Java Servlet规范中，最基础的域名获取方式是通过HttpServletRequest对象提供的getServerName()方法，对于简单的应用架构，即客户端直接连接Tomcat或Jetty等应用服务器，该方法能够正确返回主机名，开发者会结合getScheme()和getServerPort()来拼接完整的URL。
这种方式在现代微服务或云原生架构中显得力不从心，当应用服务器部署在Nginx或API网关之后时，getServerName()获取的往往是Nginx配置的upstream名称，或者是内网IP地址（如127.0.0.1或192.168.x.x），而非用户在浏览器地址栏输入的域名，这是因为Servlet容器看到的请求来源是代理服务器，而非真实的客户端。单纯依赖标准API会导致重定向链接错误、静态资源加载失败以及OAuth回调地址不匹配等严重问题。
反向代理环境下的请求头解析机制
为了解决上述问题，业界通用的做法是利用HTTP请求头来传递原始主机信息，当反向代理（如Nginx）接收到客户端请求后,它会在转发给后端Java应用的请求中添加特定的描述性头部。
最关键的请求头包括X-Forwarded-Host和Host。X-Forwarded-Host专门用于记录原始请求的Host字段，而标准的Host头部在经过代理时有时会被代理服务器自身的监听地址覆盖，还需要关注X-Forwarded-Proto，它用于标识原始协议是HTTP还是HTTPS，这对于解决“混合内容”错误至关重要。
专业的获取逻辑应当遵循优先级原则： 首先检查X-Forwarded-Host，如果存在则直接使用；其次检查标准的Host请求头；最后才回退到request.getServerName(),这种分层判断机制能够最大程度地兼容各种代理配置。
构建通用的域名获取工具类
为了在项目中统一管理域名获取逻辑，避免代码散落各处，建议封装一个专业的工具类，以下是一个经过实战检验的Java实现方案，它综合考虑了代理转发、端口默认值以及协议判断：
import javax.servlet.http.HttpServletRequest;
public class DomainUtils {
public static String getDomain(HttpServletRequest request) {
String domain = request.getHeader("X-Forwarded-Host");
if (domain == null || domain.isEmpty()) {
domain = request.getHeader("Host");
}
if (domain == null || domain.isEmpty()) {
domain = request.getServerName();
}
// 处理端口号，去除80或443等默认端口，保持URL简洁
int port = request.getServerPort();
String scheme = getScheme(request);
// 如果Host头中已经包含了端口（example.com:8080），则不需要额外拼接
if (domain.contains(":")) {
return scheme + "://" + domain;
}
// 判断是否需要拼接端口
if (("http".equalsIgnoreCase(scheme) && port != 80) ||
("https".equalsIgnoreCase(scheme) && port != 443)) {
return scheme + "://" + domain + ":" + port;
}
return scheme + "://" + domain;
}
private static String getScheme(HttpServletRequest request) {
String scheme = request.getHeader("X-Forwarded-Proto");
if (scheme == null || scheme.isEmpty()) {
scheme = request.getScheme();
}
return scheme;
}
}
这段代码的核心价值在于： 它不仅获取了域名，还智能地补全了协议和端口，在Nginx配置了SSL卸载的情况下，Java应用接收到的请求往往是HTTP，但通过读取X-Forwarded-Proto，工具类能正确识别出原始请求是HTTPS,从而生成正确的安全链接。
Spring Boot框架下的最佳实践
在Spring Boot生态中，获取域名的方式可以更加优雅，虽然上述工具类在Spring中依然通用，但Spring Framework提供了UriComponentsBuilder类,能够更方便地构建URL。
在Controller层，可以直接注入HttpServletRequest，或者利用HttpServletWebRequest，对于React式编程或WebFlux环境，则应使用ServerHttpRequest对象，其getHeaders().getHost()方法已经封装了部分代理逻辑。值得注意的是，若在Spring Boot中使用了ForwardedHeaderFilter，框架会自动修改request的包装器，使得getServerName()和getScheme()直接返回代理后的真实值，从而简化了业务代码的复杂度。 建议在配置类中显式注册该Filter，以实现对RFC 7239标准的支持。
安全性与性能考量
在获取域名的过程中，安全性是不可忽视的一环。必须防范Host Header注入攻击。 由于域名通常是从用户可控的请求头中获取的，恶意用户可以伪造Host或X-Forwarded-Host为钓鱼网站地址，如果应用直接将获取到的域名用于缓存Key生成或密码重置链接,将导致严重的安全漏洞。
专业的解决方案是引入“域名白名单机制”。 在获取到域名后，必须与系统配置的合法域名列表（如app.example.com, api.example.com）进行比对，如果获取的域名不在白名单内，应直接抛出异常或回退到配置的默认域名，对于频繁调用的场景，可以将合法域名列表预编译为正则表达式或HashSet,以减少字符串匹配带来的性能损耗。
相关问答
Q1：为什么在Nginx反向代理下，Java通过request.getRequestURL()获取的URL不包含域名？
A1：request.getRequestURL()实际上是基于getScheme()、getServerName()和getServerPort()以及getRequestURI()拼接而成的，在Nginx反向代理模式下，Java应用视Nginx为客户端，因此getServerName()获取的是Nginx的内网地址或upstream名称，而非浏览器中的域名，要解决这个问题，需要在Nginx配置中添加proxy_set_header Host $host;和proxy_set_header X-Forwarded-Proto $scheme;,并在Java端优先读取这些Header。
Q2：如何处理获取域名时的端口号问题，避免URL中出现多余的:80或:443？
A2：在拼接URL时，应遵循标准协议端口规范，如果协议是HTTP且端口为80，或者协议是HTTPS且端口为443，则应在最终结果中省略端口号，代码中应增加逻辑判断：只有当端口是非标准端口时，才将端口号拼接到域名后面，要注意检查Host请求头本身是否已经包含了端口号（例如localhost:8080）,避免重复拼接。
通过以上严谨的逻辑与代码实现，Java开发者可以在任何复杂的网络架构下，精准、安全地获取请求域名，为Web应用的功能稳定性提供坚实保障，如果您在具体的实施过程中遇到特殊的代理配置问题，欢迎在评论区分享您的架构细节,我们将共同探讨最优解。
