ProxySQL closes idle Sequel Ace frontend sessions after ~15 minutes although no matching timeout is configured

[gausssss]

Environment

• ProxySQL version: 2.5.5-10-g195bd70
• Deployment: Docker Compose on an Amazon Linux 2 bastion host
• Backend: Amazon Aurora MySQL
• Client: Sequel Ace for macOS, connected through an SSH tunnel

Description

When Sequel Ace connects to Aurora MySQL through ProxySQL over an SSH tunnel, the connection is
consistently lost after approximately 15 minutes of complete inactivity.

The same Sequel Ace connection through the same bastion host, but directly to the Aurora endpoint
without ProxySQL, remains connected for at least 20 minutes.

The issue only occurs when ProxySQL is in the path.

Expected behavior

The idle frontend session should remain connected until the configured ProxySQL frontend idle
timeout (mysql-wait_timeout) expires, or ProxySQL should return a clear error explaining why the
session is closed.

Actual behavior

After approximately 15 minutes of inactivity, Sequel Ace shows:

Connection Lost
Sequel Ace appears to have lost the connection to the server, or the server has stopped
responding.

ProxySQL logs:

MySQL_Thread.cpp:3942:process_all_sessions():
[WARNING] Closing unhealthy client connection 172.20.0.1:<client_port>

The corresponding sessions disappear from stats.stats_mysql_processlist.

## Reproduction steps

1. Create a new Sequel Ace connection through SSH to ProxySQL port <my-port>.
2. Execute:

   SELECT 1;

3. On the ProxySQL Admin interface, record the session details:

   SELECT SessionID, cli_host, cli_port, hostgroup, command, time_ms
   FROM stats.stats_mysql_processlist
   WHERE user = '<my-user>';

4. Do not execute SQL or operate Sequel Ace for 15–20 minutes.
5. Execute:

   SELECT 1;

6. The Sequel Ace connection is lost.

## Relevant findings

### Aurora session values

Both direct Aurora connections and ProxySQL connections report:

SELECT
  @@session.wait_timeout,
  @@session.interactive_timeout,
  @@session.autocommit,
  DATABASE();

Result:

wait_timeout        = 600
interactive_timeout = 600
autocommit          = 1
DATABASE()          = NULL

However, direct Aurora connections remain alive for at least 20 minutes.

### No active transaction

SELECT *
FROM information_schema.innodb_trx
WHERE trx_mysql_thread_id = CONNECTION_ID();

Result: empty set.

### Relevant ProxySQL global variables

mysql-wait_timeout              = 28800000  # 8 hours
mysql-default_query_timeout     = 86400000  # 24 hours
mysql-max_transaction_idle_time = 14400000  # 4 hours
mysql-max_transaction_time      = 14400000  # 4 hours
mysql-connection_max_age_ms     = 0
mysql-use_tcp_keepalive         = false
mysql-tcp_keepalive_time        = 0
mysql-multiplexing              = true
mysql-session_idle_ms           = 1

We also tested:

mysql-use_tcp_keepalive = true
mysql-tcp_keepalive_time = 60

The issue still reproduced.

### Query rules

No active query rule has a non-NULL timeout value.

The user is routed by this rule:

rule_id: <my-rule_id>
username: <my-user>
destination_hostgroup: <my-hostgroup>
timeout: NULL
apply: 1

### Packet capture

We captured FIN/RST packets during reproduction:

sudo tcpdump -i any -nn -tttt \
  'tcp port <my-port> and (tcp[tcpflags] & (tcp-fin|tcp-rst) != 0)'

For the affected ProxySQL client sessions, the first FIN was sent by the ProxySQL container:

172.20.0.2:<my-port> > 172.20.0.1:<client_port>: Flags [F.]

The Docker proxy and SSHD then propagated the connection close.

## Question

Is there any ProxySQL 2.5.5 behavior, undocumented setting, or known issue that can cause an idle
frontend session to be marked unhealthy and closed after approximately 15 minutes, despite:

- mysql-wait_timeout being 8 hours,
- no matching query-rule timeout,
- no active transaction, and
- ProxySQL itself sending the first FIN packet?

[renecannao]

Hi,

This is unlikely a ProxySQL issue, but an environment issue, perhaps Docker setting.

MySQL_Thread.cpp:3942:process_all_sessions():
[WARNING] Closing unhealthy client connection 172.20.0.1:<client_port>

Is there anything else before that? ^^^
It seems that from ProxySQL's point of view, the client disconnected.
This is why I suspect it is something in between (Docker).

[gausssss]

Thank you. I captured the log context before the unhealthy client connections were closed.

I reproduced the issue even when connecting through the SSH tunnel directly to the container bridge IP (172.20.0.2:), bypassing Docker's published-port docker-proxy. ProxySQL is still used in this test.

At the exact time of the disconnect, the following messages appear immediately before the client connections are closed:

2026-09-03 00:14:09 MySQL_Thread.cpp:3631:process_data_on_data_stream():
[WARNING] Detected broken idle connection on
<aurora-cluster-endpoint>:3306

2026-09-03 00:14:09 MySQL_Thread.cpp:3942:process_all_sessions():
[WARNING] Closing unhealthy client connection 172.20.0.1:<client-port>
[WARNING] Closing unhealthy client connection 172.20.0.1:<client-port>

tcpdump also shows ProxySQL (172.20.0.2:) sending FIN to both client connections at the same time.
The ProxySQL log timestamp is UTC; tcpdump is JST.

[renecannao]

That drastically changes the story.
The backend connection is dropped, and proxysql immediately drops the frontend connection.
This likely means that multiplexing is disabled, and when the backend connections is dropped, proxysql has no other option but to drop the client connection too, that additionally means that multiplexing is disabled.
You should try to look into stats_mysql_query_digests to identify which query/ies are disabling multiplexing.

[gausssss]

I opened a new Sequel Ace connection without manually running any diagnostic SQL.
ProxySQL immediately showed two idle backend sessions for the same user:

• SessionID 1895: client port 57938, backend local port 52516
• SessionID 1896: client port 57950, backend local port 52534

Both sessions remained in Sleep and retained their backend connections.

At 2026-09-03 02:43:10 UTC, tcpdump captured the first FIN packets from the Aurora endpoint:

• 10.2.21.39:3306 -> backend local port 52516
• 10.2.21.39:3306 -> backend local port 52534

At the same time ProxySQL logged:

• Detected broken idle connection
• Closing unhealthy client connection 172.20.0.1:57938
• Closing unhealthy client connection 172.20.0.1:57950

The corresponding sessions disappeared from stats_mysql_processlist immediately afterward.

I also confirmed:

• mysql-multiplexing=true
• No active runtime_mysql_query_rules with multiplex set
• The frontend user has fast_forward=0
• transaction_persistent=1
• stats_mysql_processlist.extended_info is NULL for these sessions

[renecannao]

Please check stats_mysql_query_digest , as said earlier, to identify which query/ies are disabling multiplexing.

I opened a new Sequel Ace connection without manually running any diagnostic SQL.
ProxySQL immediately showed two idle backend sessions for the same user:

That suggests that Sequel Ace opened two connections , ran queries on both of them, and these queries disabled multiplexing.

stats_mysql_processlist.extended_info is NULL for these sessions

extended_info is NULL only if mysql-show_processlist_extended=0

[gausssss]

I enabled mysql-show_processlist_extended.
The affected sessions now show "MultiplexDisabled":true and "user_variable":true in extended_info.
However, the query digests updated when opening a new Sequel Ace connection only show SET NAMES, SHOW VARIABLES, SHOW DATABASES, SELECT @@global.max_allowed_packet, and information_schema queries; none contains @ user variables.