こんにちは！データベースとAPIの裏側を覗き見するのが大好きな、君の身近な先輩エンジニアです。
新しい技術やツールに触れるとき、最初に立ちはだかる最大の壁……それが「接続エラー」ですよね。特に、PostgreSQLの公式管理ツールである「pgAdmin」を使い始めた初期によく遭遇するのが、あの冷酷なメッセージ「Connection refused（接続が拒否されました）」です。
画面の向こうで「え、俺何か悪いことした？」と冷や汗をかいている君の姿が目に浮かびます。大丈夫。このエラーは、データベースの世界への第一歩を踏み出したエンジニアなら誰もが一度は通る「通過儀礼」のようなものです。
今回は、この「Connection refused」の正体を暴き、二度と怯えなくて済むように5つの原因と解決策を、現場のリアルな知見を交えて優しく丁寧に解説していきます。これをマスターすれば、明日からのDB管理が劇的に楽になりますよ。
—
そもそも、pgAdminとPostgreSQLの関係って？
本題に入る前に、少しだけ基本を押さえましょう。
- PostgreSQL: データを安全に保管し、複雑な検索を高速にこなしてくれる「データベース本体（サーバー）」。
- pgAdmin: そのデータベースの中身を、グラフィカルでリッチな画面から操作・確認するための「GUIクライアント（管理ツール）」。
つまり、pgAdminで「Connection refused」が出るということは、「管理画面（pgAdmin）から、データベース本体（PostgreSQL）に話しかけようとしたけれど、ドアを閉められて門前払いされた状態」を意味しています。
—
接続エラーを撃退する！「Connection refused」原因と解決策5選
それでは、なぜドアが閉ざされているのか、原因を上から順に探っていきましょう。
原因1：PostgreSQLサーバー自体が起動していない
最もシンプルで、かつ最も多いミスがこれです。「そもそもサーバーの電源が入っていない」状態です。
- 解決策（Macの場合 / Homebrew）：
# PostgreSQLのステータス確認と起動
brew services list
brew services start postgresql
- 解決策（Linux / Ubuntuの場合）：
sudo systemctl status postgresql
sudo systemctl start postgresql
- 先輩からのワンポイント：
PCを再起動した直後などは、バックグラウンドサービスが自動立ち上がりしていないことがあります。まずは「サーバー、息してる？」と確認するクセをつけましょう。
—
原因2：ポート番号が間違っている（デフォルトの罠）
PostgreSQLのデフォルトの通信ポートは `5432` です。しかし、別のバージョンのPostgreSQLがすでに同居していたりすると、勝手に `5433` などの別ポートに割り振られることがあります。
- 解決策：
pgAdminでサーバーを登録する際の「Connection」タブを確認してください。
- Host name/address: `localhost` （または `127.0.0.1`）
- Port: 本当に `5432` ですか？（設定ファイルやターミナルのログを確認）
—
原因3：`postgresql.conf` が外部からのアクセスを拒絶している
PostgreSQLのセキュリティ設定の心臓部である `postgresql.conf` では、デフォルトで「ローカル（自分のPC内）からの通信しか受け付けない」ようになっています（特にDocker環境などでハマりがちです）。
- 解決策：
`postgresql.conf` ファイルを開き、`listen_addresses` の設定を確認・変更します。
# postgresql.conf の設定例
# すべてのIPアドレスからの接続を許可する場合（開発環境用）
listen_addresses = ”
※設定を変更した後は、PostgreSQLの再起動を忘れないでくださいね。
—
原因4：`pg_hba.conf` でアクセス権限（パスワード認証など）が弾かれている
「通信は通ったけど、お前誰だ？」という認証エラーがこれに該当します。PostgreSQLの門番である `pg_hba.conf`（Host-Based Authentication）が、あなたのIPアドレスや接続方式を拒否しています。
- 解決策：
`pg_hba.conf` ファイルの末尾に、以下のような行を追加して、ローカルからのパスワード付き接続を許可します。
# TYPE DATABASE USER ADDRESS METHOD
# IPv4 local connections:
host all all 127.0.0.1/32 md5
# またはパスワード認証に scram-sha-256 を使っている場合
host all all 127.0.0.1/32 scram-sha-256
ここを書き換えた場合も、必ずPostgreSQLの再起動が必要です。
—
原因5：Dockerを使っている場合、ポートフォワーディングが抜けている（最頻出！）
現代の開発現場では、PostgreSQLをDockerコンテナで動かすことが多いですよね。ここで初心者が100%と言っていいほど引っかかるのが「Dockerのポートマッピング（ポートフォワーディング）」です。
コンテナの中にあるPostgreSQLは、いわば「要塞（島）」の中にいます。外の世界（あなたのPCのpgAdmin）からアクセスするには、要塞の橋（ポート）架けが必要です。
- 解決策（docker-compose.yml の例）：
`docker-compose.yml` に、以下の `ports` 設定が正しく書かれているか確認してください。
version: ‘3.8’
services:
postgres:
image: postgres:15
environment:
POSTGRES_USER: myuser
POSTGRES_PASSWORD: mypassword
POSTGRES_DB: mydb
ports:
# 「ホスト側の5432番」を「コンテナ側の5432番」に繋ぐ！
- “5432:5432”
もしここが抜けていると、いくらpgAdminの設定を頑張っても、永遠に「Connection refused」の壁は破れません。コンテナを一度落として再ビルド（`docker compose up -d –build`）しましょう。
—
まとめ：エラーメッセージはPostgreSQLからの「ラブレター」
いかがでしたでしょうか？
「Connection refused」という冷たいエラーメッセージも、裏にある仕組み（プロセス、ポート、設定ファイル、Dockerの壁）を知っていれば、「あ、ここを直せばいいんだな」と優しく対話できるようになります。エラーは敵ではなく、正しい道に導いてくれるサインなのです。
これを機に、pgAdminとPostgreSQLの絆を深めて、快適なデータベースライフを楽しんでくださいね。わからないことがあったら、いつでも先輩を頼ってください！