Technical Support: Intermittent "Access Denied" and "Disconnecting during switch auth" in ProxySQL 3.0.3 / MySQL 8.4 group replication Cluster

[On-Off]

Dear René,

I am writing to you to request technical guidance regarding an intermittent authentication issue we are encountering in our production environment. We are utilizing ProxySQL as a database proxy for a MySQL Group Replication cluster, specifically within a credential-fetching flow (our user authentication mechanism).

Environment Details

• ProxySQL Version: 3.0.3-291-gcce161b

• MySQL Backend Version: 8.4.6-6 (Group Replication)

• Architecture: Kubernetes-based deployment.

• Authentication Config: The backend MySQL 8.4.6 instances are using caching_sha2_password. ProxySQL is configured with mysql-default_authentication_plugin='mysql_native_password'.

  
  

The Issue

We are observing intermittent failures during the client-to-proxy handshake. The flow involves an application service fetching credentials and immediately attempting to establish a connection. While some connections succeed, some fail with an "Access Denied" error during the authentication switch.

Logs & Error Trace (Anonymized)

From the ProxySQL error logs, we see the following sequence during a failure event:

1. Handshake Disconnection:

Plaintext

2026-04-27 15:16:17 MySQL_Protocol.cpp:1556:PPHR_1(): [ERROR] User 'db_user_app'@'10.x.x.x' is disconnecting during switch auth

2. Access Denied (WrongCredentials):

Plaintext

2026-04-27 15:16:17 MySQL_Session.cpp:5501:handler___status_CONNECTING_CLIENT___STATE_SERVER_HANDSHAKE_WrongCredentials(): [ERROR] ProxySQL Error: Access denied for user 'db_user_app'@'10.x.x.x' (using password: YES)

Technical Observations

1. Version Specifics: This is appearing with the newer MySQL 8.4.6-6 LTS branch. We suspect the interaction between ProxySQL 3.0.x and the updated authentication defaults in MySQL 8.4 may be a contributing factor.

2. Auth Switch Logic: The log PPHR_1() suggests the disconnection occurs exactly when the protocol attempts to switch authentication methods.

3. Credential Sync: We have confirmed that the user credentials in mysql_users match the backend exactly. The issue is intermittent, which suggests the credentials themselves are technically correct, but the handshake state machine is failing under certain conditions (latency, concurrency, or driver-specific behavior).

4. Client Driver: The application is using [mysql-connector-j-8.2.0].

Questions for Support

1. With ProxySQL 3.0.3, are there known issues or race conditions when handling the AuthSwitchRequest for MySQL 8.4 backends, specifically regarding the caching_sha2_password vs mysql_native_password fallback?

   (I can see one issue https://github.com/sysown/proxysql/issues/4596, but it was in proxysql 2.6, can this still happen in 3.X?)

2. Does the PPHR_1() error code pinpoint whether the ProxySQL worker thread is terminating the session due to a timeout, or if the client driver is sending an unexpected response to the AuthSwitch packet?

3. Are there recommended mysql-threshold or mysql-connection variables in 3.0.x that should be tuned specifically for high-frequency credential-fetching flows to prevent these handshake drops?

   
   

   For both(mysql & proxysql) the used versions I see caching_sha2_password, is by default supported, still any explicit configuration needed at either side?

   Proxysql:

   +-------------------------------------+-----------------------+

   | Variable_name                       | Value                 |

   +-------------------------------------+-----------------------+

   | mysql-default_authentication_plugin | caching_sha2_password |

   +-------------------------------------+-----------------------+

   
   
   

We appreciate your time and the incredible work you've done with ProxySQL. Any direction you can provide to stabilize this auth-switch behavior would be invaluable.

Best regards,

Pravata

[René Cannaò]

Hi Pravata,

Thanks for the detailed report.

Quick note: this list is community best-effort — for production root-causing on your environment, please reach out via https://proxysql.com/services/support/ and we'll dig in properly.

Short version of what I think is happening:

PPHR_1 logs "disconnecting during switch auth" only when the client sends a 5-byte (header-only) packet in response to ProxySQL's AuthSwitchRequest or its \x04 "perform full authentication" byte. So it's the driver tearing the flow down, not a ProxySQL timeout. The follow-up "Access denied" is generic — credentials were never actually compared.

One thing worth checking: your message mentions mysql_native_password as the configured plugin, but the variable dump shows caching_sha2_password. On a multi-replica K8s deployment, an inconsistency across pods alone can produce this kind of intermittency. Confirm runtime_global_variables agrees on every replica.

Assuming the effective value is caching_sha2_password, the path is: greeting advertises caching_sha2 → stored password is the $A$0… hash → ProxySQL emits \x04 (full-auth) → on an unencrypted hop, Connector/J 8.2.0 won't send the cleartext password and disconnects. Once any session completes full-auth, the cleartext is cached and subsequent logins for that user fast-path through — that's the intermittency.

Two ways to fix, pick one:

1) Enable TLS on the client→ProxySQL hop (useSSL=true). Note: allowPublicKeyRetrieval=true alone won't help here — ProxySQL doesn't support public-key retrieval over an unencrypted channel, so SSL is the actual requirement for full-auth with hashed passwords.

2) Store the password as cleartext in mysql_users.password and LOAD MYSQL USERS TO RUNTIME — full-auth is then never requested.

Force mysql_native_password end-to-end, but on MySQL 8.4 you must INSTALL COMPONENT 'file://component_mysql_native_password' (disabled by default in 8.4).

Personally I recommend option 1.

Relevant docs:

https://proxysql.com/documentation/authentication-methods/

https://www.proxysql.com/documentation/mysql-8-0/

https://proxysql.com/blog/enhancing-database-security-with-proxysql-2-6-0-caching_sha2_password/

Best,

René

[On-Off]

Thanks for the feedback! Rene, will get this checked.

Just to correct my earlier mail, both proxysql and Mysql are using caching_sha2_password only, no is being used mysql_native_password anywhere.