mod_authn_socache是为mod_auth_basic等认证模块提供共享内存缓存的辅助模块，不直接认证而缓存结果，可将高频请求认证耗时从5ms降至0.1ms以内；需按socache_shmcb→authn_socache→auth_basic顺序加载，并配置CacheProvider、AuthnCacheSOCache和AuthnCacheTimeout。
mod_authn_socache 是什么，为什么值得用
mod_authn_socache 不是独立认证模块，而是为其他认证模块（比如 mod_auth_basic、mod_auth_digest）提供共享内存缓存层。它本身不处理密码校验，只把校验结果（成功/失败、用户属性等）存进共享对象缓存（socache），避免每次请求都重复查数据库或调用外部脚本。
真实压力往往来自高频重复访问同一资源的用户——比如前端静态资源被 CDN 回源、健康检查探针、或内部服务轮询。这时候，哪怕后端认证逻辑只需 5ms，每秒 1000 次请求也会带来 5 秒纯认证开销。启用 mod_authn_socache 后，命中缓存的请求认证耗时可压到 0.1ms 以内。
注意：mod_authn_socache 必须和具体认证模块配合使用，单独加载它没效果。
必须启用的模块和基础配置顺序
Apache 加载模块有依赖顺序，mod_socache_shmcb（或其他 socache 提供者）必须在 mod_authn_socache 之前加载，而后者又必须在实际认证模块（如 mod_auth_basic）之前加载。
- 确认已启用：
mod_socache_shmcb、mod_authn_socache、mod_auth_basic（或 mod_auth_digest）
- 在
httpd.conf 或 mods-enabled/ 中按此顺序加载（顺序错会导致启动失败或缓存不生效）：
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so
LoadModule authn_socache_module modules/mod_authn_socache.so
LoadModule auth_basic_module modules/mod_auth_basic.so
mod_socache_shmcb、mod_authn_socache、mod_auth_basic（或 mod_auth_digest）httpd.conf 或 mods-enabled/ 中按此顺序加载（顺序错会导致启动失败或缓存不生效）：如果用的是 Debian/Ubuntu 的 a2enmod，执行顺序无关，但模块本身仍需满足依赖链；建议用 httpd -M | grep -E "(socache|authn|basic)" 确认加载顺序和状态。
关键配置项：CacheProvider 和 AuthnCacheSOCache
缓存行为由两个核心指令控制：
-
CacheProvider：指定底层缓存实现和参数。最常用的是 shmcb（基于共享内存的环形缓冲区）：
CacheProvider shmcb:/var/cache/apache2/socache-shmcb(512000)
括号内是缓存大小（字节），512KB 足够支撑约 2000 个用户条目（每个条目约 250B）
-
AuthnCacheSOCache：告诉认证模块用哪个缓存提供者。值必须与 CacheProvider 的别名一致（默认就是 shmcb）：
AuthnCacheSOCache shmcb
-
AuthnCacheTimeout：缓存条目有效期（秒），默认 300（5 分钟）。对密码变更敏感的场景可设为 60；若后端用户数据极少变动，可提到 1800
CacheProvider：指定底层缓存实现和参数。最常用的是 shmcb（基于共享内存的环形缓冲区）：CacheProvider shmcb:/var/cache/apache2/socache-shmcb(512000)括号内是缓存大小（字节），512KB 足够支撑约 2000 个用户条目（每个条目约 250B）
AuthnCacheSOCache：告诉认证模块用哪个缓存提供者。值必须与 CacheProvider 的别名一致（默认就是 shmcb）：AuthnCacheSOCache shmcb
AuthnCacheTimeout：缓存条目有效期（秒），默认 300（5 分钟）。对密码变更敏感的场景可设为 60；若后端用户数据极少变动，可提到 1800完整示例（放在 <Directory> 或虚拟主机内）：
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
<Directory "/var/www/private">
AuthType Basic
AuthName "Restricted Area"
AuthBasicProvider file
AuthUserFile /etc/apache2/.htpasswd
AuthnCacheSOCache shmcb
AuthnCacheTimeout 300
Require valid-user
</Directory>
注意：AuthBasicProvider 仍指向 file，mod_authn_socache 只在它之后介入缓存结果，不改变认证源。
容易被忽略的坑：缓存键冲突与调试方法
缓存键（cache key）默认只包含用户名 + 认证域（AuthName），不包含密码哈希方式或后端路径。这意味着：
- 如果多个
<Directory> 使用相同 AuthName 但不同 AuthUserFile，会出现“张冠李戴”：用户 A 在域 X 登录成功，缓存后，用户 B 在域 Y（同名）可能直接被放行
-
mod_auth_digest 和 mod_auth_basic 共享同一缓存区时，若 AuthName 相同，Digest 的 nonce 校验可能误命中 Basic 的缓存条目（极少见但可能）
<Directory> 使用相同 AuthName 但不同 AuthUserFile，会出现“张冠李戴”：用户 A 在域 X 登录成功，缓存后，用户 B 在域 Y（同名）可能直接被放行mod_auth_digest 和 mod_auth_basic 共享同一缓存区时，若 AuthName 相同，Digest 的 nonce 校验可能误命中 Basic 的缓存条目（极少见但可能）调试是否生效：
- 开启
LogLevel authn_socache:trace4，查看日志中是否有cache hit或cache miss - 用
curl -v -u user:pass http://site/private/触发一次认证，再改密码重试——若第二次仍成功且日志显示cache hit，说明缓存正在工作 - 检查
/var/cache/apache2/socache-shmcb文件是否存在且被 Apache 进程写入（注意 SELinux/AppArmor 可能阻止写入）
缓存失效不是实时的，AuthnCacheTimeout 到期才清理；没有手动 flush 接口。如果急需清除，只能重启 Apache 或删掉 socache 文件（会清空全部缓存）。
