在JSP开发中，获取当前服务器的域名并非简单的调用一个API即可解决，最稳健且符合生产环境要求的方案是结合 request 对象的基础方法与对反向代理头部信息的检查，这种组合策略能够确保无论是直接访问容器，还是经过Nginx等负载均衡转发，亦或是处理HTTPS协议转换，系统都能准确获取用户浏览器中实际访问的域名，这不仅关乎链接的正确跳转，更是SEO优化中防止链出权重分散、确保URL规范化的关键技术环节。
基础API解析与局限性分析
在Java Servlet规范中，获取域名最基础的方法是使用 javax.servlet.http.HttpServletRequest 接口提供的API，最常用的方法是 request.getServerName()，该方法返回请求头中Host字段对应的主机名部分，如果用户访问 http://www.example.com:8080/context，getServerName() 将返回 www.example.com。
仅仅依赖这一个方法在实际业务中存在巨大的局限性，它默认不包含端口号，如果应用部署在非80端口（如8080），直接使用该方法构建的URL将缺失端口信息，导致用户无法访问，也是最致命的问题，当服务器前端部署了反向代理服务器（如Nginx、Apache）或负载均衡器时，getServerName() 往往会返回内部服务器的IP地址（如 192.168.1.10）或者代理服务器配置的内部主机名，而非用户在浏览器中输入的真实域名，这将导致生成的回调链接、静态资源引用或重定向地址全部失效。
处理协议与端口的完整方案
为了构建一个完整的URL，除了域名，我们还需要考虑协议（HTTP或HTTPS）以及端口号，在JSP中，request.getScheme() 用于获取协议（返回 “http” 或 “https”），request.getServerPort() 用于获取端口。
但在反向代理场景下，getScheme() 往往也会失效，因为用户与代理之间是HTTPS，而代理与JSP容器之间通常是HTTP，导致JSP认为请求是明文传输，为了解决这个问题，工业界通用的标准是检查特定的HTTP请求头，我们需要检查 X-Forwarded-Proto 头部来确定原始协议，检查 X-Forwarded-Host 或 X-Forwarded-Server 来获取原始域名。
应对反向代理与负载均衡的专业策略
在现代化的高并发Web架构中，JSP应用几乎不直接暴露在公网，而是隐藏在Nginx或阿里云SLB等负载均衡之后，编写获取域名的代码必须具备“感知代理”的能力。
核心逻辑应当遵循“头部优先，API兜底”的原则：
- 首先检查
X-Forwarded-Host请求头，如果该头存在，说明请求经过了代理，该头的值即为真实的域名（可能包含端口）。 X-Forwarded-Host不存在，则回退到检查Host请求头。- 如果以上都不存在，最后才使用
request.getServerName()。
对于协议的判断，同样需要优先检查 X-Forwarded-Proto，如果该头的值为 https，则强制将协议识别为HTTPS,忽略容器内部的HTTP设置。
最佳实践代码实现
为了在JSP页面中复用该逻辑,建议封装一个工具方法或在JSP声明块中编写如下核心逻辑：
<%!
/**
* 获取访问的完整域名（包含协议、域名、端口）
*/
public String getDomainName(HttpServletRequest request) {
String scheme = request.getScheme();
String serverName = request.getServerName();
int serverPort = request.getServerPort();
String contextPath = request.getContextPath();
// 检查反向代理头部
String forwardedProto = request.getHeader("X-Forwarded-Proto");
if (forwardedProto != null && !forwardedProto.isEmpty()) {
scheme = forwardedProto;
}
String forwardedHost = request.getHeader("X-Forwarded-Host");
if (forwardedHost != null && !forwardedHost.isEmpty()) {
// X-Forwarded-Host 可能包含端口，www.example.com:8080
serverName = forwardedHost.split(":")[0];
// forwardedHost 包含端口，则覆盖 serverPort
if (forwardedHost.contains(":")) {
try {
serverPort = Integer.parseInt(forwardedHost.split(":")[1]);
} catch (NumberFormatException e) {
// 保持默认端口
}
}
} else {
// 检查 Host 头部
String hostHeader = request.getHeader("Host");
if (hostHeader != null && !hostHeader.isEmpty()) {
serverName = hostHeader.split(":")[0];
if (hostHeader.contains(":")) {
try {
serverPort = Integer.parseInt(hostHeader.split(":")[1]);
} catch (NumberFormatException e) {
// 保持默认端口
}
}
}
}
// 构建基础URL
StringBuilder domain = new StringBuilder();
domain.append(scheme).append("://").append(serverName);
// 仅在非标准端口时添加端口
if (("http".equalsIgnoreCase(scheme) && serverPort != 80)
|| ("https".equalsIgnoreCase(scheme) && serverPort != 443)) {
domain.append(":").append(serverPort);
}
return domain.toString();
}
%>
SEO与安全视角的域名规范化
从SEO（搜索引擎优化）的角度来看，准确获取域名并进行URL规范化至关重要。搜索引擎会将 www.example.com 和 example.com 视为两个不同的站点，从而导致权重分散，通过上述代码获取到当前访问的域名后，开发者应结合业务逻辑，判断是否需要进行301重定向，如果业务主推带 www 的域名，当检测到用户访问不带 www 的域名时，应利用获取到的域名信息构建目标URL，并返回 301 Moved Permanently 状态码，告知搜索引擎这是永久跳转,从而集中权重。
在安全性方面，动态获取域名可以有效防止“恶意跳转”漏洞，如果在代码中硬编码跳转地址，一旦服务器迁移或域名变更，极易产生维护疏漏，而动态获取当前请求的域名作为基准，再拼接相对路径，可以确保生成的链接始终在当前域名上下文中,避免被利用跳转至非法第三方网站。
相关问答
Q1：在JSP中，为什么有时候获取到的域名是 127.0.0.1 或者局域网IP？
A： 这种情况通常发生在服务器前端配置了反向代理（如Nginx）或负载均衡，但没有正确配置代理传递头部信息，JSP容器接收到的请求来源是代理服务器的内部回环地址或局域网IP，解决方法是在反向代理配置中添加 proxy_set_header Host $host; 和 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 等指令，并在JSP代码中优先读取 X-Forwarded-Host 头部。
Q2：如何判断当前请求是否使用了 HTTPS 协议，特别是在使用了 SSL 卸载（SSL Offloading）的情况下？
A： 在 SSL 卸载场景下，用户与代理之间是 HTTPS，代理与 JSP 之间是 HTTP，直接使用 request.isSecure() 或 request.getScheme() 会返回 false 或 “http”，必须通过检查 request.getHeader("X-Forwarded-Proto") 的值来判断，如果该值等于 “https”，则表明原始请求是安全的，应将当前请求视为 HTTPS 处理。
如果您在JSP开发中遇到了域名获取不准确或代理配置的问题，欢迎在评论区分享您的具体环境配置,我们将为您提供针对性的排查建议。
