Communications link failureの原因と直し方｜MySQL

com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure は、MySQL Connector/J（MySQL の JDBC ドライバ）が、MySQL サーバーとの通信そのものに失敗したときに出るエラーです。 SQL の間違いやパスワードの間違いではなく、ネットワークか接続の状態に原因があります。

原因は大きく2つに分かれ、メッセージの2行目を見ればどちらかが分かります。

この記事では、それぞれの原因を実際に起こし、出たメッセージと直し方を並べました。

確認環境：Ubuntu 24.04、MySQL 8.0.46、OpenJDK 21.0.10、Docker 29.4.3（確認日 2026年10月10日）。Connector/J のメッセージは、Connector/J 9.7.0 のソース（メッセージの定義とメッセージを組み立てる処理）で確認しました。下層のネットワークのエラーは、Java の Socket で同じ接続を試して再現しています。

メッセージの読み方

com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
    at com.mysql.cj.jdbc.exceptions.SQLError.createCommunicationsException(...)
    ...
Caused by: com.mysql.cj.exceptions.CJCommunicationsException: Communications link failure
    ...
Caused by: java.net.ConnectException: Connection refused

Connector/J は、最後に通信した時刻とサーバーの wait_timeout を比べてメッセージを作ります。最後の通信から wait_timeout 以上たっていれば、2行目に続けて is longer than the server configured value of 'wait_timeout' という説明と、接続の有効性を使う前に確かめる・タイムアウトを延ばすといった対処の案が付きます。

一番下の Caused by で原因を分ける

同じ接続を Java の Socket で試すと、Caused by: に出る例外を再現できます。次のプログラムは、DB のホストとポートに TCP でつながるかだけを調べます（ドライバが無くても動くので、切り分けに便利です）。

import java.net.*;

/** DB のホスト・ポートに TCP でつながるかだけを調べる: java Probe.java ホスト ポート */
public class Probe {
    public static void main(String[] a) throws Exception {
        String host = a[0];
        int port = Integer.parseInt(a[1]);
        long t = System.currentTimeMillis();
        try (Socket s = new Socket()) {
            s.connect(new InetSocketAddress(host, port), 5000);   // 5秒でタイムアウト
            System.out.println("OK: " + s.getRemoteSocketAddress());
        } catch (Exception e) {
            System.out.println(e + "  (" + (System.currentTimeMillis() - t) + " ms)");
        }
    }
}

$ java Probe.java localhost 3306
OK: localhost/127.0.0.1:3306
$ java Probe.java localhost 3307
java.net.ConnectException: Connection refused  (7 ms)
$ java Probe.java 10.255.255.1 3306
java.net.SocketTimeoutException: Connect timed out  (5008 ms)
$ java Probe.java db 3306
java.net.UnknownHostException: db  (9 ms)

Connection refused はすぐに返り、Connect timed out はタイムアウトの時間（上の例は5秒）だけ待たされます。画面が固まってから出るなら経路、すぐ出るならポートと見当を付けられます。

例1：MySQL が起動していない・ポートが違う

Caused by: java.net.ConnectException: Connection refused

ポートを変えている（3307 など）ことに気づかず、接続URLは 3306 のまま、というケースも多くあります。

例2：bind-address が 127.0.0.1 で、他のマシンからつながらない

MySQL の設定 bind-address が 127.0.0.1 だと、同じマシンの中からしか接続できません。Ubuntu の apt で入れた MySQL は、この設定になっています。

mysql> SHOW VARIABLES LIKE 'bind_address';
+---------------+-----------+
| bind_address  | 127.0.0.1 |
+---------------+-----------+

$ ss -ltn | grep 3306
LISTEN 0      151        127.0.0.1:3306       0.0.0.0:*

この状態で、Docker のコンテナ（別のマシンと同じ扱いになる）からホストの MySQL に接続すると、Connection refused になりました。

== コンテナ → 172.17.0.1:3306（ホストの MySQL）
java.net.ConnectException: Connection refused  (23 ms)

直し方：MySQL の設定ファイル（Ubuntu は /etc/mysql/mysql.conf.d/mysqld.cnf）を変え、MySQL を再起動します。

[mysqld]
bind-address = 0.0.0.0        # すべてのネットワークで待ち受ける（特定のIPだけにもできる）

$ ss -ltn | grep 3306
LISTEN 0      151          0.0.0.0:3306       0.0.0.0:*
== コンテナ → 172.17.0.1:3306
OK: /172.17.0.1:3306

待ち受けを広げたら、ファイアウォールで接続元を絞ることと、MySQL のユーザーを 'app'@'192.168.10.%' のように接続元のホストを指定して作ることを合わせて行います。ユーザーのホストが合わないと、今度は Host '...' is not allowed to connect to this MySQL server（ERROR 1130）になります。

例3：Docker で localhost に接続している

アプリを Docker のコンテナで動かすと、コンテナの中の localhost はコンテナ自身を指します。コンテナから localhost:3306 に接続すると、ホストの MySQL が動いていても Connection refused になりました。

== コンテナ → localhost:3306
java.net.ConnectException: Connection refused  (28 ms)

docker compose では、アプリが MySQL の準備完了より先に起動して、このエラーになることもあります。depends_on だけでは、コンテナが起動するまでしか待ちません。ヘルスチェックを付けて、準備ができるまで待たせます。

services:
  db:
    image: mysql:8.4
    environment:
      MYSQL_ROOT_PASSWORD: example
      MYSQL_DATABASE: app
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-uroot", "-pexample"]
      interval: 5s
      retries: 20
  app:
    build: .
    environment:
      SPRING_DATASOURCE_URL: jdbc:mysql://db:3306/app
    depends_on:
      db:
        condition: service_healthy

例4：つながっていた接続が wait_timeout で切られた

MySQL は、何も通信しない接続を wait_timeout（既定 28800 秒＝8時間） で切ります。夜間に使われなかった接続を、朝いちばんに使うと出る、というのが典型です。

wait_timeout を5秒にして、7秒待ってから SQL を送りました。

mysql> SET SESSION wait_timeout = 5;
mysql> SELECT 'before' AS t;
+--------+
| before |
+--------+
（7秒待つ）
mysql> SELECT 'after' AS t;
ERROR 4031 (HY000): The client was disconnected by the server because of inactivity. See wait_timeout and interactive_timeout for configuring this behavior.

MySQL 8.0.24 以降のサーバーは、切る前にこのエラー（4031）を送ります。Connector/J 9.7.0 のソースでは、このエラーを受け取ると CommunicationsException として投げる作りになっているため、Java ではメッセージに The client was disconnected by the server because of inactivity が入ります。それより前のサーバーでは、The last packet successfully received from the server was 28,800,xxx milliseconds ago の形になります。

直し方：wait_timeout を延ばすのではなく、接続プール側で、サーバーに切られる前に接続を入れ替えるようにします。Spring Boot の既定の接続プールは HikariCP です。

# application.yml（Spring Boot + HikariCP）
spring:
  datasource:
    url: jdbc:mysql://db:3306/app
    hikari:
      max-lifetime: 1740000      # 29分。DB やネットワーク機器の切断時間より数秒以上短く
      keepalive-time: 120000     # 2分ごとに使っていない接続を確認する
      connection-timeout: 30000  # プールから接続を借りるまで待つ時間

クラウドの DB では、ロードバランサーや NAT ゲートウェイの無通信タイムアウトが wait_timeout より短いことがあります。この場合、MySQL の設定を延ばしても直りません。maxLifetime をその時間より短くします。

接続URLの autoReconnect=true は、Connector/J の説明でも「推奨しない」とされています。トランザクションの途中で再接続すると、セッションの状態やデータの整合性に影響するためです。

例5：TLS のバージョンが合わない

Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

TLS 1.0・1.1 しか使えない以前の版の MySQL に、新しい Java から接続すると出ます。最近の Java は TLS 1.0・1.1 を既定で無効にしているためです。TLS 1.1 だけを許可した Java のクライアントで接続すると、同じメッセージになりました。

似ているが別のエラー

確認の手順（チェックリスト）

よくある質問

Q. 朝いちばんの処理だけエラーになり、2回目からは動きます。 A. 夜間に使われなかった接続が、wait_timeout やネットワーク機器のタイムアウトで切られています（例4）。HikariCP の maxLifetime を、切られる時間より短くします。

Q. MySQL Workbench やコマンドからはつながるのに、アプリからだけつながりません。 A. 接続している場所が違うことが多い原因です。Workbench は自分のPCから、アプリはサーバーやコンテナから接続しています。アプリが動いているマシン（コンテナ）の中で Probe.java や nc を実行して確かめます。

Q. autoReconnect=true を付ければ直りますか。 A. Connector/J の説明では、この設定は推奨されていません。切れた接続を使った SQL はエラーになり、次のトランザクションから再接続する動きで、セッションの状態が失われます。接続プールの設定で対応します。

Q. MariaDB の JDBC ドライバでも同じですか。 A. エラーの文言は違いますが、原因と直し方の考え方（つながらないのか、途中で切れたのか、Caused by を見る）は同じです。

まとめ

• Communications link failure は通信の失敗。SQL・パスワードの問題ではない
• 2行目が「not received any packets」なら、一度もつながっていない。ポート・bind-address・Docker の localhost・ファイアウォールを調べる
• 「successfully received ... milliseconds ago」や inactivity なら、途中で切れた。wait_timeout とネットワーク機器のタイムアウトを調べる
• 一番下の Caused by: が本当の原因。Connection refused はポート、Connect timed out は経路
• 途中で切れる問題は、HikariCP の maxLifetime を切断時間より短くして直す。autoReconnect には頼らない

参考・出典

確認日はいずれも 2026年10月10日です。

• MySQL 8.0 Reference Manual「MySQL server has gone away」：https://dev.mysql.com/doc/refman/8.0/en/gone-away.html
• MySQL Connector/J 9.7.0 ソース（メッセージの定義・接続プロパティの説明）：https://github.com/mysql/mysql-connector-j
• HikariCP（README の設定項目）：https://github.com/brettwooldridge/HikariCP
• Docker Docs「Control startup and shutdown order in Compose」：https://docs.docker.com/compose/how-tos/startup-order/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。