必须在MySQL中创建host为ProxySQL服务器实际IP的专用账号，如'proxysql_user'@'192.168.10.5'，并授予SELECT/INSERT/UPDATE/DELETE及必需的REPLICATION CLIENT权限，同时确保MySQL bind-address开放且防火墙放行该IP访问3306端口。
MySQL端必须创建host为ProxySQL服务器IP的专用账号
ProxySQL不是MySQL的“内置模块”，它走的是标准TCP连接，所以MySQL根本不认识“ProxySQL”这个概念——只认user@host二元组。你不能指望在MySQL里建一个'proxy'@'%' 就完事，那样等于把权限敞给所有IP；也不能用'proxy'@'localhost'，因为ProxySQL默认从远端（比如192.168.10.5）连过来，根本不会走本地socket。
正确做法是：查清ProxySQL所在机器的出口IP（不是127.0.0.1，也不是容器bridge IP，而是它实际发包用的那个地址），然后在MySQL中显式创建对应host的用户：
CREATE USER 'proxysql_user'@'192.168.10.5' IDENTIFIED BY 'StrongPass!2026';GRANT SELECT, INSERT, UPDATE, DELETE ON myapp.* TO 'proxysql_user'@'192.168.10.5';-
GRANT REPLICATION CLIENT ON *.* TO 'proxysql_user'@'192.168.10.5';（监控必需） FLUSH PRIVILEGES;
别漏掉REPLICATION CLIENT权限，否则ProxySQL监控会静默失败
ProxySQL依赖REPLICATION CLIENT权限定期执行SHOW SLAVE STATUS和SHOW VARIABLES LIKE 'read_only'来判断从库状态、延迟、只读性。如果只给了DML权限，它连主从拓扑都识别不了，mysql_servers表里节点状态永远是OFFLINE_HARD，但错误日志里可能只有一句模糊的Monitor module failed to connect，排查起来非常绕。
注意：REPLICATION CLIENT不等同于REPLICATION SLAVE，后者是用于搭建复制链路的，前者只是“看状态”的只读权限，最小够用即可。
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
MySQL的bind-address和防火墙要配合收紧
bind-address本身不控制谁可连，但它决定了MySQL监听在哪张网卡上。如果MySQL设了bind-address = 127.0.0.1，那ProxySQL从外部IP连必然失败——哪怕账号host对了也不行。生产环境应设为bind-address = 0.0.0.0或具体内网IP（如192.168.10.10），再靠系统防火墙补一刀：
iptables -A INPUT -p tcp --dport 3306 -s 192.168.10.5 -j ACCEPTiptables -A INPUT -p tcp --dport 3306 -j DROP
这条规则比MySQL层的@'%'更底层、更可靠，属于双重保险。
ProxySQL侧的mysql_users表密码填明文就行，但别混淆后端账号和监控账号
ProxySQL的mysql_users表里password字段填的是**后端MySQL账号的明文密码**（它内部会自动转成hash），不是ProxySQL自己的管理密码，也不是监控账号密码。容易搞混的三个账号角色：
-
ProxySQL管理账号：用
mysql -u admin -p -P 6032登录ProxySQL本身的账号，存在admin-admin_credentials变量里 -
监控账号：在MySQL里建的
'proxysql_monitor'@'192.168.10.5'，密码填进mysql-monitor_username/mysql-monitor_password变量 -
业务账号：客户端连ProxySQL时用的账号，例如
'app_user'@'192.168.10.5'，其明文密码直接写进mysql_users.password
这三者密码可以不同，但账号名和host必须跟MySQL后端严格一致，大小写、空格、下划线都不能错——ProxySQL不做任何标准化处理，原样透传。
