mysql代理用户是服务端身份委托机制，需开启check_proxy_users、显式授权grant proxy on 'alice'@'%' to 'app_user'@'%'并客户端指定--proxy-user=alice，缺一不可；current_user()返回被代理用户才表示生效。

MySQL 代理用户不是“换账号登录”，而是让一个已认证用户（如 app_user）在连接建立后，**自动切换到另一个用户的权限上下文**——所有 SQL 权限、行级策略、审计日志都按被代理者（如 alice@'%'）生效。它必须显式开启、显式授权、显式触发，漏掉任一环节就完全不生效。

必须先打开 check_proxy_users 系统变量

默认关闭，不启用就等于没配。MySQL 8.0+ 要求该变量为 ON，否则 GRANT PROXY 授权会被忽略，客户端连上去也看不到任何错误，只是 CURRENT_USER() 始终是代理者自己。

• 动态启用（重启前有效）：SET PERSIST check_proxy_users = ON;
• 永久生效：写入 my.cnf 的 [mysqld] 段，加一行 check_proxy_users=ON，然后重启 MySQL
• 验证是否生效：SELECT @@global.check_proxy_users; 返回 1 才算成功

GRANT PROXY 语法和常见翻车点

这不是普通权限授权，不能漏引号、不能省主机名、不能靠角色间接授予。核心是“被代理用户定义”必须和 CREATE USER 语句里**字面值完全一致**。

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 正确写法：GRANT PROXY ON 'alice'@'%' TO 'app_user'@'%';
• 错误写法：GRANT PROXY ON alice TO app_user（报错 ERROR 1410）
• 错误写法：GRANT PROXY ON 'alice'@'localhost' TO 'app_user'@'%'（即使 alice 在 localhost 存在，但授权时 host 不匹配就不认）
• 执行完必须 FLUSH PRIVILEGES;，否则旧版 JDBC 或某些中间件读不到新记录
• 验证授权是否落库：SELECT * FROM mysql.proxies_priv WHERE User='app_user' AND Host='%';

客户端连接时怎么触发代理？不同工具写法差异大

不是连上后再 SET，而是在 TCP 握手阶段由客户端明确声明。服务端收到 user 和 proxy_user 参数后，查 mysql.proxies_priv 表确认关系，再切换上下文。

• 命令行 mysql：mysql -uapp_user -p --proxy-user=alice（注意：不是 --user=alice）
• JDBC URL（驱动 ≥ 8.0.22）：jdbc:mysql://h:3306/db?proxyUser=alice
• Python mysql-connector-python：connect(..., proxy_user='alice')（不是 user='alice'）
• PyMySQL / MySQLdb：不原生支持；若硬要试，需用 SUPER 权限用户连上后执行 SET SESSION proxy_user = 'alice';，生产环境禁用

验证是否真生效：别只看 USER()

USER() 返回的是“谁连进来的”，CURRENT_USER() 才是“当前以谁的身份执行”。权限、审计、RLS 全部取决于后者。这是最容易误判的地方。

• 连上后立刻执行：SELECT USER(), CURRENT_USER();
• 预期输出：app_user@192.168.1.100 和 alice@% ——只有后者匹配被代理用户，才说明代理成功
• 如果 CURRENT_USER() 还是 app_user@%，说明前面某步失败了：变量没开、授权没刷、客户端参数写错、或被代理用户不存在/密码为空（MySQL 8.0+ 强制要求有密码）

真正难的不是配置步骤，而是理解“代理用户”和“被代理用户”之间没有密码继承、没有自动同步、也没有中间状态——它是一次性、服务端强制的身份替换。只要 CURRENT_USER() 不变成目标用户，权限就不可能切换过去，所有后续操作都在原用户上下文中执行。