Authentication through PgBouncer involves two login hops. The application’s authentication to PgBouncer and PgBouncer’s authentication to PostgreSQL may use different settings, users and error timestamps. Starting with a pool_mode change can distract from a login-stage failure.
Locate the first failed login
Correlate the application driver’s SCRAM support, client-login versus server-login messages in PgBouncer, and PostgreSQL authentication logs. Zero query counts do not establish SCRAM failure: waiting, connection limits or a client that sent no query are other possibilities.
Inspect which user and credential format auth_type, auth_file or auth_query supplies without copying secrets into logs. The PgBouncer authentication reference describes restrictions on using a SCRAM secret for backend authentication. Verifiers generated independently from the same plaintext password may still differ in salt and other components.
Narrow the scope with three evidence patterns
If client authentication fails immediately with no backend login attempt, inspect the driver, user and front-end authentication contract. If PgBouncer login succeeds but server login fails, compare the backend target, role and authentication method. If both logins succeed and only particular queries fail, investigate session state and pooling compatibility. Direct database access does not establish success through the proxy.
A correction must include secure credential deployment and the version’s reload or reconnection conditions. Verify both logins and a read query over a new connection, not just an existing session. No real password or secret was retrieved and no successful SCRAM recovery was measured here.