不能直接用 getremoteaddr() 获取真实 ip，因其返回的是反向代理 ip；真实 ip 通常在 x-forwarded-for 等 header 中，但需结合可信代理校验；反射访问 tomcat 内部 request 对象虽可行，但版本依赖强、不稳定，不推荐用于生产。
在 Java Web 应用中，尤其是部署在 Tomcat 上时，通过反射获取内部 Request 对象来提取真实 IP 和原始 Header 是一种绕过标准 Servlet API 限制的非常规手段，常见于某些网关、日志埋点或安全审计场景。但需注意：这属于非公开 API 访问，依赖 Tomcat 版本实现，稳定性差，不推荐用于生产核心逻辑。
为什么不能直接用 getRemoteAddr()？
标准 Servlet 接口中的 HttpServletRequest.getRemoteAddr() 返回的是直连客户端（如反向代理 Nginx、SLB）的 IP，而非终端用户真实 IP。真实 IP 通常藏在 X-Forwarded-For、X-Real-IP 等 Header 中，但这些 Header 可被伪造，需结合代理链可信配置校验。
反射访问 Tomcat 的 Request 内部对象
Tomcat 的 org.apache.catalina.connector.Request 是 HttpServletRequest 的具体实现类，其内部持有原始 socket 地址、解析后的 Header 映射及未过滤的请求数据。可通过以下方式尝试获取：
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 先将标准
HttpServletRequest强转为org.apache.catalina.connector.Request（需确认实际运行时类型） - 若失败，用反射获取其
request字段（例如在org.apache.catalina.connector.RequestFacade中，该字段名常为request或realRequest） - 再通过反射调用
getRemoteAddr()或读取remoteAddr字段——此值在 Tomcat 解析X-Forwarded-For后可能已被修正（取决于RemoteIpFilter是否启用） - Header 读取可绕过 Servlet 规范的“只读映射”限制，直接访问底层
headers成员（通常是org.apache.tomcat.util.http.MimeHeaders），支持获取重复 Header 或原始大小写 key
获取真实 IP 的安全建议
单纯依赖反射获取 IP 风险高，更稳妥的方式是：
- 在 Tomcat
server.xml中配置RemoteIpFilter，并设置remoteIpHeader="X-Forwarded-For"和可信代理列表（internalProxies） - 使用
HttpServletRequest.getRemoteAddr()—— 经RemoteIpFilter处理后已为可信真实 IP - 若必须读原始 Header，优先用标准
getHeader("X-Forwarded-For")，再按逗号分割取最左非信任代理 IP（需配合白名单判断） - 避免直接反射读取 Tomcat 内部字段，因其在不同版本中字段名、访问权限（private/final）、类路径均可能变化（如 Tomcat 10+ 迁移至
jakarta.*命名空间）
Header 处理的注意事项
Tomcat 对 Header 的处理有缓存和规范化行为：
-
MimeHeaders中的 key 默认转为小写存储，但原始大小写可通过getName(int index)获取 - 重复 Header（如多个
Set-Cookie）在getHeaderNames()中只出现一次，但MimeHeaders支持遍历全部 value - 反射读取前需检查字段是否为
transient或被安全管理器禁止访问 - Spring Boot 内嵌 Tomcat 时，
Request实例可能被包装多次（如ContentCachingRequestWrapper），需逐层 unwrap
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
