Rocky LinuxにPostgreSQLを入れて起動できても、次にぶつかりやすいのが 「別端末から接続できない」 問題です。
原因はだいたい次の4つに集約されます。
- PostgreSQLが外部IPで待ち受けていない（listen_addresses）
- 接続元が許可されていない（pg_hba.conf）
- OSのFWで遮断されている（firewalld）
- SELinuxがブロックしている（SELinux）
この記事では、最小で安全に設定を進めるチェックリストをまとめます。
この記事の対象読者
- Rocky LinuxでPostgreSQLを動かし始めた
- ローカル接続はできたが、別PC（クライアント）から繋ぎたい
- なるべく安全に（開けすぎずに）設定したい
まず決める：ローカル運用？リモート運用？
設定が変わるので、最初に判断します。
ローカル運用（同じサーバ内のアプリだけ）
- listen_addresses：基本は変更不要（localhostのままでOK）
- firewalld：開放不要
- pg_hba.conf：ローカルのみ許可でOK
リモート運用（別PCから接続する）
- listen_addresses：外部から届くように設定が必要
- firewalld：5432/TCPの開放が必要（ただし接続元を絞るのが理想）
- pg_hba.conf：接続元IPを許可
- SELinux：環境によって追加対応が必要
この記事は「リモート運用」を中心に書きます（ローカル運用の人は “必要な項目だけ” でOK）。
設定ファイルの場所を確認する（迷子防止）
PostgreSQLの設定場所はインストール方法で差が出ます。確実なのは、psqlから確認する方法です。
sudo -iu postgres
psql -c "SHOW config_file;"
psql -c "SHOW hba_file;"
psql -c "SHOW data_directory;"出力されたパスをメモしておくと、以降の作業が迷いません。
exitで抜けます：
exitlisten_addresses を設定（外部から届くようにする）
2-1) 現在値を確認
sudo -iu postgres
psql -c "SHOW listen_addresses;"
exit2-2) 設定変更（例）
postgresql.conf を開いて、listen_addresses を変更します。
推奨（安全寄り）：サーバの特定IPだけを指定
検証で一時的に使う例：*（全IFで待受）※後で絞るのが安全
編集例（viでもnanoでもOK）：
sudo vi
設定例：
listen_addresses = ‘*’
port = 5432
- は楽ですが開きすぎになりやすいので、運用では サーバのIP指定 か 接続元の制限（pg_hba + FW） とセットで使うのが安全です。
- pg_hba.conf を設定（接続元を最小で許可）
次は「誰が・どんな認証で」接続できるかを決めます。
3-1) まずは基本形を理解
pg_hba.conf は上から順に評価され、最初に一致したルールが適用されます。
代表的な項目：
TYPE：host / local
DATABASE：対象DB
USER：対象ユーザー
ADDRESS：接続元（IP/CIDR）
METHOD：認証方式（例：scram-sha-256 など）
3-2) 例：特定のPC(192.168.1.10)だけ許可（推奨）
pg_hba.conf を編集します。
sudo vi
追記例（接続元を1台に絞る）：
IPv4 remote access (example: allow only one client)
host appdb appuser 192.168.1.10/32 scram-sha-256
複数台なら /24 等で範囲指定もできますが、最初は /32（1台）がおすすめです。
もし scram-sha-256 が使えない/合わない場合は、環境により md5 が使われるケースもあります。まずは「安全寄り（scram）」で試し、合わなければバージョンや既存設定に合わせて調整しましょう。
- firewalld（FW）を確認して必要なら開放する
4-1) firewalldが動いているか確認
sudo systemctl status firewalld –no-pager
4-2) 5432を開ける（必要な場合のみ）
検証として簡単に開ける例：
sudo firewall-cmd –add-port=5432/tcp –permanent
sudo firewall-cmd –reload
sudo firewall-cmd –list-ports
より安全にするなら「接続元IPを限定するFW設定（rich rule）」が理想です。
ただ、まずは疎通を確立してから“絞る”ほうがトラブル切り分けが簡単です（本番運用は必ず絞ってください）。
- SELinux の確認（接続できない原因になりやすい）
SELinuxが有効な場合、ポリシーにより通信やアクセスが制限されることがあります。
5-1) 現在の状態を確認
getenforce
Enforcing：有効（制限あり）
Permissive：警告のみ
Disabled：無効5-2) まずは「ログで原因を見る」
SELinuxが絡む場合、ログにヒントが出ます。
sudo journalctl -xe --no-pager | tail -n 200SELinuxは “無効にすれば解決” になりがちですが、運用では推奨しにくいです。
まずはログで何がブロックされているかを見て、必要最小の対処に寄せるのが安全です。
設定を反映する（reload/restart）
postgresql.conf や pg_hba.conf を変えたら反映します。
まずは reload を試す：
sudo systemctl reload postgresql
反映されない/起動周りを変えたなら restart：
sudo systemctl restart postgresql
- 最終チェック（ここまでで原因がほぼ見える）
7-1) PostgreSQLが外部で待受しているか
sudo ss -lntp | grep 5432
0.0.0.0:5432 や サーバIPでLISTENしていればOK。
7-2) サーバ側ログを見る（接続試行の痕跡が出る）
sudo journalctl -u postgresql –no-pager -n 200
つまずきパターン別：最短の切り分け
パターンA：クライアントからタイムアウト（応答なし）
- まず listen_addresses と firewalld を疑う
- ss -lntp | grep 5432 で待受確認
- firewalldで5432が閉じていないか
パターンB：接続はできるが「no pg_hba.conf entry」
- pg_hba.conf に接続元IPが許可されていない
- /32 のIPが合っているか確認
- ルールの順番（上から評価）に注意
- reload/restart忘れに注意
パターンC：認証失敗（password authentication failed）
- ユーザー/パスワードが違う、または METHOD が合っていない
- ユーザーが存在するか
- scram-sha-256/md5 の整合
- パスワードを再設定する