401 Unauthorized表明认证失败，主因是Token传递或校验环节异常：客户端使用过期Token、memcached驱逐Token、或多节点路由错误；需优先检查openstack token show的expires_at及memcached驱逐指标。
Token验证失效不是“突然出错”，而是客户端、服务端、缓存层三方状态不一致的集中暴露。最直接的判断依据是：命令或API调用返回 401 Unauthorized，但 openstack token issue 却能成功生成新Token。
为什么openstack token issue成功，但其他命令却报401？
这说明Keystone认证服务本身在线、凭据有效，问题出在Token的“传递”或“校验”环节。常见原因有三个：
- 客户端使用了过期或已失效的旧Token（比如硬编码在脚本里，或未及时刷新）
- Keystone后端（如memcached）丢掉了该Token——不是因为过期，而是被主动驱逐
- 请求发到了错误的Keystone实例（多节点部署时DNS轮询/负载均衡配置不当）
优先检查 openstack token show 输出中的 expires_at 字段，再比对当前系统时间。如果时间未过期，就基本排除客户端Token过期问题，转向缓存和路由排查。
如何确认memcached是否在“偷偷删Token”？
Keystone默认用memcached做Token后端时，不会报错提示“Token不存在”，只会静默返回401。关键要看memcached自身指标：
- 执行
echo "stats" | nc 127.0.0.1 11211 | grep -E "(limit_maxbytes|evictions)" - 若
evictions值持续增长（比如每分钟几十次），且limit_maxbytes明显偏小（如67108864= 64MB），就是内存不足导致Token被强制清理 - 临时验证：把Keystone后端切到SQL（修改
keystone.conf中[token]段的provider和driver），重启服务。若401消失，即可锁定memcached问题
注意：切换后端需同步迁移存量Token（keystone-manage token_flush 清空旧缓存，否则混合使用会更乱）。
openstack token issue返回401，但凭据明明是对的
这时问题不在Token本身，而在认证请求根本没到达Keystone，或Keystone拒绝了该请求。按顺序排查：
- 检查
OS_AUTH_URL是否指向v3端点（如http://controller:5000/v3），而非v2或根路径；v2已弃用，v3根路径会触发版本发现，容易因DNS或SSL失败中断 - 运行
curl -v $OS_AUTH_URL/v3，看是否返回300 Multiple Choices或直接超时/证书错误 - 确认
OS_IDENTITY_API_VERSION=3已设置，否则客户端可能降级尝试v2，而v2 endpoint已被禁用 - 检查Keystone服务状态：
systemctl status apache2（若用Apache托管）或systemctl status keystone（若用WSGI）
特别注意：某些OpenStack发行版（如RDO）默认关闭v2，但旧版客户端或脚本仍默认走v2，这种隐式降级会导致“凭据正确却认证失败”的假象。
Token在Nova/Neutron服务里验证失败，但Keystone日志没记录
说明请求压根没送到Keystone，或者被中间件拦截。典型场景是：
- Neutron/Nova配置中
auth_url指向了内网不可达的地址（如127.0.0.1:5000），而服务实际运行在另一台机器上 - 服务配置了
memcache_servers，但指向的是不可达或版本不兼容的memcached实例（如启用了SASL但客户端未配） - 防火墙或安全组放行了5000端口，但没放行memcached的11211端口，导致服务间Token校验超时失败
查证方法：在nova/neutron服务节点上手动执行 curl -v http://<keystone-ip>:5000/v3</keystone-ip> 和 nc -zv <memcache-ip> 11211</memcache-ip>，比看日志更快定位网络断点。
