mod_ident在现代环境中基本失效，因其依赖客户端运行identd服务并响应RFC 1413协议，而当前终端设备普遍不支持、NAT/防火墙拦截端口113、主流HTTP客户端完全忽略该流程，导致99%以上请求返回超时或“No user”。
Apache 的 mod_ident 无法可靠获取远程用户名，不建议用于审计目的。
为什么 mod_ident 在现代环境中基本失效
mod_ident 依赖客户端主动响应 IDENT 协议（RFC 1413），即 Apache 向客户端 TCP 源端口发起连接，请求对方 identd 服务返回“用户名”。但现实情况是：
- 绝大多数终端用户设备（Windows/macOS/Linux 桌面、手机、浏览器）不运行
identd服务，也无默认开启机制 - NAT、防火墙、家用路由器普遍拦截或丢弃来自外网的 IDENT 请求（端口 113）
- 主流浏览器、HTTP 客户端（curl、wget、Python requests）完全忽略 IDENT 流程，不提供也不响应
- 即使服务器端启用
mod_ident，99% 以上请求收到的是超时或No user响应
启用 mod_ident 的实际操作与典型日志表现
若仍需验证行为（例如内网测试环境），可按如下步骤启用，但请预期日志几乎全为空值：
- 确认模块已加载：
a2enmod ident（Debian/Ubuntu）或检查LoadModule ident_module modules/mod_ident.so（RHEL/CentOS） - 在虚拟主机或目录配置中添加：
IdentityCheck On - 在
LogFormat中加入%u占位符，例如：LogFormat "%h %l %u %t \"%r\" %>s %O" combined - 重启 Apache：
systemctl restart apache2（或httpd）
日志中 %u 字段通常显示为 - 或空字符串；极少数内网 SSH 网关或老旧代理可能返回真实用户名，但这不是 Web 请求本身的属性，而是其背后 TCP 连接的附属信息。
真正可用的替代方案：从认证层而非网络层获取用户标识
审计所需的“谁访问了什么”，必须基于可信身份源，而非不可控的网络协议。可行路径包括：
- 启用
mod_auth_basic或mod_auth_digest，配合Require valid-user，此时%u记录的是认证通过的用户名（非 IDENT） - 对接 LDAP/OAuth2 的
mod_authnz_ldap或mod_auth_openidc，日志中%u即为目录服务中的账号 - 应用层透传：后端应用（如 PHP/Python）解析
Authorization头或 session，写入自定义日志字段（如%{X-User-ID}i） - 反向代理场景：由 Nginx 或 Traefik 在转发时注入
X-Forwarded-User，Apache 用%{X-Forwarded-User}i记录
IDENT 协议本质是上世纪 80 年代为 FTP/Telnet 设计的粗粒度溯源手段，它不加密、不可靠、不可控。任何将审计依据押在 %u（IDENT）上的配置，上线后都会发现日志里全是破折号——这不是配置错了，是协议本身在今天已经没有生存土壤。
