mod_session仅提供会话生命周期控制和cookie管理，需配合mod_session_socache等后端模块才能实现完整会话功能；缺任一模块将导致session on失效或启动报错。
mod_session 本身不“实现会话管理”，它只提供会话生命周期控制和 Cookie 管理能力；真正的会话数据存储必须由额外模块（如 mod_session_socache、mod_session_dbd）配合完成，否则 Apache 启动会报 AH01821: unable to configure socache 或直接忽略 Session 指令。
为什么 Session On 不生效？——模块加载缺一不可
Apache 的会话功能是模块化拼装的，不是开个开关就能用。常见失效原因不是配置写错，而是模块没全加载：
-
mod_session：提供基础会话框架（Session、SessionCookieName等指令） -
mod_session_cookie：负责生成/解析 Cookie（若用 Cookie 存 session ID） -
mod_session_crypto：加密 session 数据或 Cookie 内容（强烈建议启用） -
mod_session_socache或mod_session_dbd：实际存取 session 数据的后端（没有它，Session On形同虚设）
检查方式：apachectl -M | grep session。缺任何一个，都会导致配置静默失败或启动报错。
SessionCookieName 命名不当会导致 400 错误
看似只是起个名字，但 SessionCookieName 实际参与构造缓存 key 和 HTTP 头解析。如果值含空格、点号、下划线或非 ASCII 字符，mod_session_socache 在拼接 memcached key 时会出错，Apache 直接返回 400 Bad Request，日志里却只写 Invalid argument。
- ✅ 安全命名：
SessionCookieName sessionid path=/;httponly;secure - ❌ 危险命名：
SessionCookieName my.session path=/（点号触发 key 格式异常） - ❌ 危险命名：
SessionCookieName user_session（下划线在部分 socache 后端中被截断）
推荐统一用纯小写+数字，长度控制在 16 字符内，避免任何特殊符号。
Session socache memcache 配置中两个 timeout 完全不同
memcache 方案里最容易混淆的是两个 timeout 参数，它们作用域和单位都不同：
-
memcache://127.0.0.1:11211?timeout=5中的timeout=5是 TCP 连接超时（秒），影响 Apache 启动和每次写入前的连接建立 -
Session socache memcache timeout 600中的600是 session 最大空闲时间（秒），即用户 10 分钟无操作后 session 自动过期
如果只调大后者却忽略前者，在高延迟网络或 memcached 负载高时，Apache 可能频繁超时失败，表现为 session 随机丢失，而非超时清除。
mod_session_crypto 加密不是可选项，而是安全刚需
默认情况下，mod_session_socache 把 session 数据 base64 编码后直接存入 memcached —— 没有加密，没有签名。攻击者只要能访问 memcached（比如通过 misconfigured telnet 或 SSRF），就能读取、篡改任意用户的 session 内容。
- 必须启用
mod_session_crypto并设置SessionCryptoPassphrase -
SessionCryptoCipher aes-256-cbc+SessionCryptoHmacProvider openssl是当前最稳妥组合 - 密钥不能硬编码在配置里，应通过
file:/path/to/key从权限受限文件读取（chmod 600）
真正难的不是配置这几句，而是确保所有 Apache 工作进程都能一致读到同一份密钥文件——在容器或 systemd --private-tmp 场景下，路径可能根本不可见。
