在Java开发中,获取当前服务器的域名主要通过解析HttpServletRequest对象实现，但在生产环境（特别是经过反向代理或负载均衡）下，必须结合X-Forwarded-Host等请求头进行综合判断，以确保获取的准确性，最核心的解决方案是：优先检查代理服务器转发的Host头信息，若不存在则降级使用请求对象的ServerName属性，同时根据协议头动态处理HTTP与HTTPS，并智能过滤默认端口，从而输出标准的、无冗余的域名地址。
基于Servlet API的基础获取方式
在标准的Java Web应用中，最直接的方法是利用javax.servlet.http.HttpServletRequest接口提供的内置方法，这是大多数开发者入门时最先接触的方式，适用于应用服务器直接对外提供服务，没有中间层代理的场景。
核心代码逻辑通常涉及getServerName()、getScheme()和getServerPort()三个方法的组合。getServerName()返回请求头中的Host属性对应的主机名；getScheme()返回协议类型（如http或https）；getServerPort()返回服务器监听的端口号。
单纯依赖这些方法存在明显的局限性,如果用户通过http://example.com:80访问，getServerPort()会返回80，但在构建URL时，标准HTTP协议默认端口80是不需要显式展示的，如果直接拼接，生成的链接就会变成http://example.com:80，这在SEO和用户体验上都是不规范的。在基础获取方式中，必须编写逻辑判断：当端口为80（HTTP）或443（HTTPS）时，应自动省略端口号的拼接。
应对反向代理与负载均衡的专业方案
在现代企业级架构中,Java应用很少直接暴露在公网，通常前面会部署Nginx、Apache或云厂商的负载均衡（SLB/ELB），在这种情况下，Java应用接收到的请求并非来自真实的用户浏览器，而是来自反向代理。
request.getServerName()往往获取的是内网IP（如192.168.1.10）或者代理服务器配置的本地主机名（如localhost），这会导致生成的跳转链接失效，为了解决这个问题，业界通用的标准是代理服务器在转发请求时，会在HTTP头中添加特定的字段，最常见的是X-Forwarded-Host（记录原始域名）和X-Forwarded-Proto（记录原始协议）。
专业的解决方案要求开发者编写一个健壮的工具类，按照优先级顺序读取这些头部信息，具体逻辑如下：
- 获取域名：首先检查
X-Forwarded-Host请求头，如果该头存在且不为空，则使用该值；否则降级使用request.getServerName()。 - 获取协议：首先检查
X-Forwarded-Proto请求头，如果该头指示为https，则强制使用HTTPS协议；否则检查request.isSecure()；最后才使用request.getScheme()。 - 获取端口：如果使用了
X-Forwarded-Host，通常该头包含了端口信息（如example.com:8080），此时无需额外获取端口，如果未使用代理头，则需像基础方案一样处理getServerPort()，并过滤默认端口。
这种方案能够完美适配Docker容器化部署、Kubernetes Service以及各类云负载均衡环境，是目前最权威、最可信的获取方式。
基于URL字符串的解析技术
除了获取当前请求的域名,Java开发中还常涉及从任意URL字符串中提取域名的需求，在处理爬虫数据或分析第三方回调链接时，Java核心库提供的java.net.URL类和java.net.URI类是处理此类问题的标准工具。
使用java.net.URL类时，可以通过new URL(urlString)实例化对象，然后调用getHost()方法即可获得纯净的域名，需要注意的是，getHost()方法会自动处理端口号，只返回主机部分，如果需要包含端口的完整Authority信息，则应使用getAuthority()。
对于更复杂的场景,或者需要验证URL合法性的场景，java.net.URI是更推荐的选择，因为它对RFC 2396规范的实现更为严格，能够更好地处理特殊字符编码问题。独立的见解是：在处理非结构化的用户输入URL时，建议优先使用URI类进行解析和规范化，以避免因格式错误导致的程序异常。
安全性与最佳实践考量
在获取域名的过程中,安全性是一个不容忽视的专业维度，一个常见的安全漏洞是“Host头攻击”，如果应用程序盲目信任Host请求头或X-Forwarded-Host头，并将其用于密码重置链接或敏感跳转，攻击者可以通过伪造Host头（如将Host改为evil.com）来生成恶意链接，诱导用户点击从而窃取Token。
在获取域名后，必须进行白名单验证，开发者应当在配置文件中维护一个允许的域名列表，或者在代码中硬编码合法的域名前缀，当获取到的域名不在白名单内时，应抛出异常或回退到默认的系统域名，这种“零信任”的处理方式是构建高安全性Web应用的关键。
对于多租户SaaS应用,域名往往对应租户的身份，在获取域名后，通常需要结合数据库查询，将域名解析为Tenant ID，这一过程应当引入缓存机制（如Redis），避免每次请求都查询数据库，从而保证系统的高性能和低延迟。
相关问答
Q1：在Spring Boot项目中，有没有更简便的方法获取当前请求的域名？
A1：虽然Spring Boot底层依然是基于Servlet API，但可以通过注入HttpServletRequest对象来简化获取过程，更高级的做法是利用Spring MVC的UriComponentsBuilder工具类，使用UriComponentsBuilder.fromRequest(request).build().toUriString()可以自动构建包含Scheme、Host、Port和Path的完整URL，针对反向代理的情况，依然需要确保服务器正确配置了ForwardedHeaderFilter，或者在Nginx中正确设置了proxy_set_header配置，否则Spring Boot依然无法识别真实的域名。
Q2：为什么我的Java应用获取的域名是IP地址而不是域名？
A2：这通常发生在两种情况下，第一种是客户端直接通过IP地址访问服务，此时请求头中的Host本身就是IP，Java应用如实返回，第二种是经过反向代理（如Nginx），但Nginx配置中遗漏了proxy_set_header Host $host;这一行指令，导致后端Java应用收到的Host头被重写为Nginx的 upstream 配置名（通常是IP），解决方法是在Nginx的location配置块中添加该指令，并确保传递了X-Forwarded-Proto等必要信息。
