infra
Platform

모듈 맵

[Network] 서비스 바인딩 주소 127.0.0.1 vs 0.0.0.0 실무

0 / 35 완료

펼치기
0 / 35 완료0%

Networking · 08 / 35

[Network] 서비스 바인딩 주소 127.0.0.1 vs 0.0.0.0 실무

데몬이 127.0.0.1에만 바인딩되어 외부 접속이 안 되는 원인을 파악하고 수정합니다

🚨INCIDENT ALERT
HIGH

API 서버를 띄웠고 로컬 curl은 성공하는데, 옆 서버에서는 Connection refused가 납니다. 방화벽을 열어도 그대로라 로그만 뒤지다 보니 서비스가 127.0.0.1에만 붙어 있었습니다.

포트가 열렸다는 말은 어디에 바인딩됐는지까지 확인해야 완성됩니다.

서비스 바인딩 주소 (127.0.0.1 vs 0.0.0.0)

"MySQL을 설치했는데 외부 애플리케이션 서버에서 연결이 안 됩니다." 이 문제의 절반 이상은 바인딩 주소 설정이 원인입니다. 이 챕터에서는 루프백과 0.0.0.0의 차이를 이해하고, 실제 설정 파일을 수정하는 방법을 익힙니다.


1. 루프백(127.0.0.1)과 0.0.0.0의 차이

이번 챕터에서 배울 것
  • 1바인딩 주소(Bind Address)의 개념과 127.0.0.1 vs 0.0.0.0의 차이
  • 2ss -tulnp 명령어로 서비스별 리스닝 주소 확인 및 해석
  • 3MySQL bind-address 설정 변경으로 외부 접속 허용
  • 4Redis bind 설정 변경 및 requirepass 인증과 함께 보안 구성
  • 5PostgreSQL listen_addresses와 pg_hba.conf 접속 허용 설정
  • 60.0.0.0 바인딩 후 방화벽으로 허용 IP 제한하는 보안 원칙
실습 환경 준비
모든 리스닝 소켓과 바인딩 주소 확인
ss -tulnp
127.0.0.1 바인딩 서비스 목록 조회 (외부 접속 불가 후보)
ss -tulnp | grep '127.0.0.1'
MySQL 바인딩 설정 파일 위치 확인
grep -rn 'bind-address' /etc/my.cnf /etc/my.cnf.d/ 2>/dev/null
💡개념

네트워크 바인딩 주소의 의미

MySQL을 설치하고 외부 서버에서 접속하려는데 "Connection refused"가 납니다. 포트 3306은 열려 있고 프로세스도 실행 중입니다. 원인은 MySQL이 127.0.0.1에만 바인딩되어 있어서 외부에서 오는 연결을 아예 받지 않기 때문입니다. 반대로 Redis를 0.0.0.0으로 열어두면 인터넷에서 인증 없이 접근 가능해지는 심각한 보안 문제가 생깁니다. 바인딩 주소가 무엇인지 알아야 이 두 상황을 정확히 통제할 수 있습니다.

네트워크 바인딩 주소의 의미

데몬(서버 프로세스)이 어떤 네트워크 인터페이스에서 연결을 받을지 지정하는 것이 바인딩 주소(Bind Address) 입니다.

주요 바인딩 주소 비교 — 세 가지 주소는 보안과 접근성 면에서 완전히 다르게 동작합니다.

바인딩 주소의미접근 가능 범위
127.0.0.1루프백(loopback)만같은 서버 내부만
0.0.0.0모든 인터페이스서버의 모든 IP로 접근 가능
192.168.1.10특정 IP만해당 IP로 들어오는 연결만
::1IPv6 루프백IPv6 로컬 전용
::IPv6 모든 인터페이스IPv6 전체

루프백(127.0.0.1/lo) 인터페이스 — 같은 서버 내에서만 접근 가능한 가장 안전한 바인딩입니다.

[서버 내부]
  프로세스 A ──→ 127.0.0.1:3306 ──→ MySQL   (성공)

[외부 클라이언트]
  앱 서버(192.168.1.100) ──→ DB 서버(192.168.1.200):3306
                             └→ Connection Refused
                                (eth0으로 들어왔지만 lo에만 바인딩)

루프백은 물리 NIC와 완전히 분리된 소프트웨어 가상 인터페이스입니다. 127.0.0.1로 들어오는 패킷은 절대 외부 네트워크로 나가지 않습니다.

0.0.0.0 — 모든 인터페이스 — 서버의 모든 네트워크 인터페이스에서 연결을 받습니다.

서버 NIC 구성:
  lo  → 127.0.0.1
  eth0 → 192.168.1.200
  eth1 → 10.0.0.200

MySQL이 0.0.0.0:3306 바인딩 시:
  → 127.0.0.1:3306 으로도 접속 가능
  → 192.168.1.200:3306 으로도 접속 가능
  → 10.0.0.200:3306 으로도 접속 가능

2. ss 명령어로 바인딩 주소 확인

💡개념

ss -tulnp 출력 해석

서비스가 어떤 주소에 바인딩됐는지 확인해야 합니다. ss -tulnp 출력에는 Local Address가 0.0.0.0:3306, 127.0.0.1:6379, :::80 등으로 나오는데, 이것이 외부 접근 가능 여부를 나타냅니다. 이 출력을 읽을 줄 알면 방화벽을 열기 전에 먼저 바인딩 주소를 확인하는 습관이 생깁니다.

ss -tulnp 출력 해석

ss -tulnp 명령어로 현재 서버의 모든 리스닝 소켓과 바인딩 주소를 확인합니다.

로컬 터미널
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part2/exam_8 && cd /tmp/networking/part2/exam_8

ss -tulnp
🔍실행 후 확인할 것
  • 핵심 출력명령 결과에서 성공/실패를 가르는 값을 먼저 확인합니다
  • 대상 식별IP, 포트, 인터페이스, 프로세스명처럼 다음 조치를 결정하는 필드를 봅니다
  • 다음 분기결과가 기대와 다르면 어느 계층을 이어서 점검할지 정합니다

옵션 설명 — 각 옵션이 바인딩 동작에 미치는 영향입니다.

옵션의미
-tTCP 소켓
-uUDP 소켓
-lLISTEN 상태만
-n이름 해석 없이 숫자로 표시
-p프로세스 정보 포함

출력 예시 분석 — LISTEN 상태인 소켓의 Local Address에서 바인딩 주소를 확인합니다.

Netid  State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port  Process
tcp    LISTEN  0       128     127.0.0.1:3306        0.0.0.0:*          users:(("mysqld",pid=1234,fd=21))
tcp    LISTEN  0       128     0.0.0.0:6379          0.0.0.0:*          users:(("redis-server",pid=5678,fd=6))
tcp    LISTEN  0       511     0.0.0.0:80            0.0.0.0:*          users:(("nginx",pid=9012,fd=7))
tcp    LISTEN  0       128     127.0.0.1:6379        0.0.0.0:*          users:(("redis-server",pid=5678,fd=5))

해석

  • 127.0.0.1:3306 → MySQL이 루프백에만 바인딩 → 외부 접속 불가
  • 0.0.0.0:6379 → Redis가 모든 인터페이스에 바인딩 → 외부 접속 가능
  • 0.0.0.0:80 → Nginx가 모든 인터페이스에서 HTTP 수신

특정 포트만 필터링 — 특정 포트의 바인딩 주소만 빠르게 확인하는 방법입니다.

로컬 터미널
# MySQL 포트만 확인
ss -tulnp | grep 3306

# Redis 포트만 확인
ss -tulnp | grep 6379

# 0.0.0.0으로 바인딩된 것만 확인
ss -tulnp | grep '0.0.0.0'

# 127.0.0.1로 바인딩된 것만 확인 (외부 접속 불가 서비스)
ss -tulnp | grep '127.0.0.1'

3. 실습: MySQL 바인딩 주소 변경

MySQL / MariaDB 외부 접속 허용 설정 양식 및 오류 예방

데이터베이스 인프라를 외부 전용 서버와 안전하게 바인딩하려면, 데이터베이스 설정 파일(/etc/mysql/my.cnf 또는 /etc/mysql/mysql.conf.d/mysqld.cnf) 내부의 bind-address 필드를 찾아 올바르게 명세해야 합니다.

  • 안전 접속 통제 양식:
    • bind-address = 127.0.0.1: 오직 로컬 서버 내부 프로세스만 DB 포트 접속 허용 (보안 극대화).
    • bind-address = 0.0.0.0: 인터넷 상의 모든 공인/사설 호스트 IP 접속 수용 (외부 웹서버 연동 시 필수).
    • 주의 (틀린 설정 예시): allow-host = 0.0.0.0 이나 /etc/mysql/access.conf 같은 파일은 표준 MySQL 바인딩 설정 키워드가 아니며, 오타로 인한 DB 가동 크래시를 유발합니다. 반드시 my.cnfbind-address 지시어를 편집해야 합니다.

MySQL / MariaDB 외부 접속 허용 설정 양식 및 오류 예방

데이터베이스 인프라를 외부 전용 서버와 안전하게 바인딩하려면, 데이터베이스 설정 파일(/etc/mysql/my.cnf 또는 /etc/mysql/mysql.conf.d/mysqld.cnf) 내부의 bind-address 필드를 찾아 올바르게 명세해야 합니다.

  • 안전 접속 통제 양식:
    • bind-address = 127.0.0.1: 오직 로컬 서버 내부 프로세스만 DB 포트 접속 허용 (보안 극대화).
    • bind-address = 0.0.0.0: 인터넷 상의 모든 공인/사설 호스트 IP 접속 수용 (외부 웹서버 연동 시 필수).
    • 주의 (틀린 설정 예시): allow-host = 0.0.0.0 이나 /etc/mysql/access.conf 같은 파일은 표준 MySQL 바인딩 설정 키워드가 아니며, 오타로 인한 DB 가동 크래시를 유발합니다. 반드시 my.cnfbind-address 지시어를 편집해야 합니다.

MySQL / MariaDB 외부 접속 허용 설정 양식 및 오류 예방

데이터베이스 인프라를 외부 전용 서버와 안전하게 바인딩하려면, 데이터베이스 설정 파일(/etc/mysql/my.cnf 또는 /etc/mysql/mysql.conf.d/mysqld.cnf) 내부의 bind-address 필드를 찾아 올바르게 명세해야 합니다.

  • 안전 접속 통제 양식:
    • bind-address = 127.0.0.1: 오직 로컬 서버 내부 프로세스만 DB 포트 접속 허용 (보안 극대화).
    • bind-address = 0.0.0.0: 인터넷 상의 모든 공인/사설 호스트 IP 접속 수용 (외부 웹서버 연동 시 필수).
    • 주의 (틀린 설정 예시): allow-host = 0.0.0.0 이나 /etc/mysql/access.conf 같은 파일은 표준 MySQL 바인딩 설정 키워드가 아니며, 오타로 인한 DB 가동 크래시를 유발합니다. 반드시 my.cnfbind-address 지시어를 편집해야 합니다.
1단계: MySQL 현재 바인딩 주소 확인

문제 상황을 재현하고 확인하는 과정부터 시작합니다.

로컬 터미널
# MySQL 리스닝 상태 확인
ss -tulnp | grep 3306

# 예상 출력 (문제 상황):
# tcp LISTEN 0 128 127.0.0.1:3306 0.0.0.0:* users:(("mysqld",pid=1234,fd=21))
#              ↑
#           여기가 127.0.0.1 → 외부 접속 불가

# MySQL 서버 변수로도 확인 가능 (MySQL 클라이언트에서)
mysql -u root -p -e "SHOW VARIABLES LIKE 'bind_address';"
# +---------------+-----------+
# | Variable_name | Value     |
# +---------------+-----------+
# | bind_address  | 127.0.0.1 |
# +---------------+-----------+

# 현재 설정 파일 확인
grep -n 'bind' /etc/my.cnf /etc/my.cnf.d/*.cnf /etc/mysql/mysql.conf.d/mysqld.cnf 2>/dev/null
2단계: MySQL bind-address 설정 변경

MySQL의 바인딩 주소는 설정 파일에서 bind-address 항목으로 지정합니다.

로컬 터미널
# 설정 파일 위치 확인 (배포판마다 다름)
# CentOS/RHEL: /etc/my.cnf 또는 /etc/my.cnf.d/mysql-server.cnf
# Ubuntu/Debian: /etc/mysql/mysql.conf.d/mysqld.cnf

# CentOS 기준 설정 파일 편집
vi /etc/my.cnf

# 또는
vi /etc/my.cnf.d/mysql-server.cnf

변경 전 설정 — PostgreSQL 기본값은 localhost만 받습니다.

INI
[mysqld]
# 기본값 — 127.0.0.1 또는 아무 설정도 없으면 암묵적 127.0.0.1
bind-address = 127.0.0.1

변경 후 설정 — 외부 접속을 허용하도록 listen_addresses를 수정합니다.

INI
[mysqld]
# 모든 인터페이스에서 연결 수락
bind-address = 0.0.0.0

# 또는 특정 IP만 (더 안전)
# bind-address = 192.168.1.200

변경 사항 적용 — 설정 변경 후 서비스를 재시작해야 반영됩니다.

위험 명령어

이 명령은 실행 중인 서비스 상태를 바꿔 순간적인 중단이나 설정 반영 실패를 만들 수 있습니다. 운영 트래픽 영향과 재시작 후 확인 명령을 먼저 준비하세요.

서버 터미널
# MySQL 재시작
systemctl restart mysqld

# 재시작 후 바인딩 확인
ss -tulnp | grep 3306
# tcp LISTEN 0 128 0.0.0.0:3306 0.0.0.0:*   ← 0.0.0.0으로 변경됨

# MySQL 서비스 상태 확인
systemctl status mysqld
3단계: Redis 바인딩 주소 변경

Redis도 기본값이 127.0.0.1인 경우가 많습니다. 외부 애플리케이션 서버에서 Redis에 접속해야 한다면 설정을 변경합니다.

로컬 터미널
# Redis 현재 바인딩 확인
ss -tulnp | grep 6379

# Redis 설정 파일 위치
# CentOS: /etc/redis/redis.conf 또는 /etc/redis.conf
# Ubuntu: /etc/redis/redis.conf

# 현재 bind 설정 확인
grep '^bind' /etc/redis/redis.conf
# bind 127.0.0.1 -::1   ← 루프백에만 바인딩

Redis 설정 변경 — bind 지시어에 허용할 IP를 추가합니다.

로컬 터미널
vi /etc/redis/redis.conf
INI
# 변경 전
bind 127.0.0.1 -::1

# 변경 후 — 모든 인터페이스
bind 0.0.0.0

# 또는 특정 IP와 루프백 모두 허용
# bind 127.0.0.1 192.168.1.200

Redis 재시작 및 확인 — 변경 후 실제로 바인딩이 변경됐는지 확인합니다.

위험 명령어

이 명령은 실행 중인 서비스 상태를 바꿔 순간적인 중단이나 설정 반영 실패를 만들 수 있습니다. 운영 트래픽 영향과 재시작 후 확인 명령을 먼저 준비하세요.

서버 터미널
systemctl restart redis

# 바인딩 확인
ss -tulnp | grep 6379
# tcp LISTEN 0 128 0.0.0.0:6379 0.0.0.0:*

# 외부에서 연결 테스트 (앱 서버에서 실행)
redis-cli -h 192.168.1.200 -p 6379 ping
# PONG  ← 성공
4단계: 0.0.0.0 노출 후 방화벽으로 접근 제한

0.0.0.0으로 바인딩하면 모든 IP에서 접근 가능해지므로, 반드시 방화벽으로 접근 가능한 IP를 제한해야 합니다.

위험 명령어

이 명령은 방화벽 정책을 변경해 현재 접속 중인 세션이나 운영 트래픽에 즉시 영향을 줄 수 있습니다. 적용 전 허용 대상 IP·포트와 롤백 명령을 확인하세요.

로컬 터미널
# CentOS — firewalld로 특정 IP에만 3306 허용
# rich rule: 192.168.1.0/24 대역에서만 MySQL 접근 허용
firewall-cmd --zone=public \
  --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="3306" accept' \
  --permanent
firewall-cmd --reload

# Ubuntu — ufw로 특정 IP에만 허용
ufw allow from 192.168.1.0/24 to any port 3306
ufw allow from 192.168.1.0/24 to any port 6379

# 방화벽 규칙 확인
firewall-cmd --list-rich-rules
# 또는
ufw status numbered

# iptables로 직접 확인 (모든 배포판)
iptables -L INPUT -n -v | grep -E '3306|6379'

보안 원칙 요약 — 바인딩 설정의 핵심 원칙입니다.

[권장 설정]
MySQL bind-address = 0.0.0.0
↓
방화벽: 192.168.1.100(앱 서버)만 3306 허용
→ 다른 모든 IP는 차단

[비권장 — 위험]
MySQL bind-address = 0.0.0.0
방화벽: 3306 전체 허용
→ 인터넷에서 누구나 MySQL에 접근 가능

4. 장애 사례 분석

증상 — 실제 터미널에서 나타나는 에러 메시지입니다.

[앱 서버 로그]
ERROR: Can't connect to MySQL server on '192.168.1.200' (111 "Connection refused")

[또는 Java Spring Boot]
com.mysql.cj.jdbc.exceptions.CommunicationsException:
Communications link failure
...
java.net.ConnectException: Connection refused (Connection refused)

원인 확인 절차 — 어느 IP로 바인딩됐는지 순서대로 확인합니다.

로컬 터미널
# DB 서버에서 실행
ss -tulnp | grep 3306
# tcp LISTEN 0 128 127.0.0.1:3306  ← 루프백에만 바인딩!

# 앱 서버에서 nc로 포트 접근 테스트
nc -zv 192.168.1.200 3306
# nc: connect to 192.168.1.200 port 3306 (tcp) failed: Connection refused

해결 과정 — 설정 파일을 수정하고 적용합니다.

위험 명령어

이 명령은 방화벽 정책을 변경해 현재 접속 중인 세션이나 운영 트래픽에 즉시 영향을 줄 수 있습니다. 적용 전 허용 대상 IP·포트와 롤백 명령을 확인하세요.

로컬 터미널
# 1. DB 서버의 my.cnf 수정
vi /etc/my.cnf
# bind-address = 127.0.0.1  →  bind-address = 0.0.0.0 으로 변경

# 2. MySQL 재시작
systemctl restart mysqld

# 3. 방화벽에서 앱 서버 IP만 허용 (반드시!)
firewall-cmd --zone=public \
  --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port protocol="tcp" port="3306" accept' \
  --permanent
firewall-cmd --reload

# 4. MySQL 계정에도 외부 접속 권한 확인
mysql -u root -p
mysql> SELECT user, host FROM mysql.user WHERE user='appuser';
# host가 'localhost'만 있다면 원격 접속 불가
# 권한 추가:
mysql> CREATE USER 'appuser'@'192.168.1.100' IDENTIFIED BY 'password';
mysql> GRANT ALL ON appdb.* TO 'appuser'@'192.168.1.100';
mysql> FLUSH PRIVILEGES;

교훈: MySQL 외부 접속 문제는 3가지를 모두 확인해야 합니다. (1) bind-address 설정, (2) OS 방화벽, (3) MySQL 사용자 host 권한

증상 — Redis 연결 거부 시 나타나는 에러입니다.

DB 클라이언트
# 외부에서 Redis 접속 후
redis-cli -h 192.168.1.200 ping
# (error) NOAUTH Authentication required

# 또는 Redis 로그에서
# WARNING: 80 bytes bleed over into next allocation
# SECURITY WARNING: You are running Redis without CONFIG command disabled

원인 분석

Redis를 0.0.0.0으로 바인딩했지만 인증(requirepass)이 설정되지 않은 경우, 또는 protected-mode가 비활성화된 경우에 발생합니다.

로컬 터미널
# Redis 설정 확인
grep -E 'requirepass|protected-mode|bind' /etc/redis/redis.conf

해결 방법 — bind 설정과 방화벽을 함께 확인합니다.

로컬 터미널
vi /etc/redis/redis.conf
INI
# 외부 바인딩 설정
bind 0.0.0.0

# 반드시 비밀번호 설정
requirepass YourStrongPassword123!

# protected-mode는 bind가 0.0.0.0이고 requirepass가 없을 때 자동 활성화
# requirepass 설정 후 비활성화 가능 (권장하지 않음)
# protected-mode no
위험 명령어

이 명령은 실행 중인 서비스 상태를 바꿔 순간적인 중단이나 설정 반영 실패를 만들 수 있습니다. 운영 트래픽 영향과 재시작 후 확인 명령을 먼저 준비하세요.

서버 터미널
systemctl restart redis

# 비밀번호로 접속
redis-cli -h 192.168.1.200 -a YourStrongPassword123! ping
# PONG

교훈: Redis를 0.0.0.0으로 열 때는 방화벽 + requirepass 인증을 반드시 함께 설정하세요. 인증 없는 Redis 노출은 랜섬웨어 감염의 주요 경로입니다.


5. 실무 현장 관점

💼
실무 맥락
현업 패턴

전형적인 3-티어 아키텍처에서의 바인딩 전략 — 계층별로 최소 권한 바인딩을 적용합니다.

[웹/앱 서버 — 192.168.1.100]
  ↓ MySQL 3306 연결
[DB 서버 — 192.168.1.200]
  MySQL: bind-address = 192.168.1.200  (또는 0.0.0.0)
  방화벽: 192.168.1.100만 3306 허용

업무 현장에서 자주 발생하는 상황

  1. 개발 완료 후 스테이징 배포: 개발 환경에서는 같은 서버에 앱+DB가 있어서 127.0.0.1로 잘 됐는데, 스테이징에서 서버를 분리하면서 연결 실패

  2. Docker Compose 환경: 같은 Compose 네트워크에 있어도 MySQL이 127.0.0.1에 바인딩이면 다른 컨테이너에서 접속 불가

  3. Kubernetes: 파드 내부에서는 127.0.0.1 바인딩도 동작하지만, 다른 파드나 서비스에서 접속하려면 0.0.0.0 바인딩 필요

체크리스트 — DB 외부 접속 설정 시 — 순서대로 점검하면 대부분의 연결 문제를 해결할 수 있습니다.

로컬 터미널
#!/bin/bash
# DB 외부 접속 설정 검증 스크립트

DB_HOST="192.168.1.200"
DB_PORT="3306"
APP_SERVER="192.168.1.100"

echo "=== DB 외부 접속 설정 검증 ==="

# 1. 바인딩 주소 확인
echo "[1] 바인딩 주소:"
ss -tulnp | grep ":${DB_PORT}"

# 2. 방화벽 규칙 확인
echo "[2] 방화벽 규칙:"
firewall-cmd --list-rich-rules 2>/dev/null | grep ${DB_PORT} || \
ufw status | grep ${DB_PORT}

# 3. MySQL 사용자 호스트 확인
echo "[3] MySQL 사용자 호스트:"
mysql -u root -p -e "SELECT user, host FROM mysql.user;" 2>/dev/null

echo "=== 검증 완료 ==="

보안 팁: 가능하다면 bind-address = 0.0.0.0 대신 앱 서버 IP를 직접 지정(bind-address = 192.168.1.200)하거나, 0.0.0.0으로 바인딩하되 방화벽에서 철저히 제한하는 방식을 사용하세요.


6. 추가 실습: PostgreSQL과 MongoDB 바인딩 확인

MySQL, Redis 외에도 많이 사용되는 데이터베이스의 바인딩 설정을 정리합니다.

PostgreSQL 바인딩 설정 변경

PostgreSQL은 listen_addresses 파라미터로 바인딩 주소를 설정합니다.

로컬 터미널
# PostgreSQL 현재 바인딩 확인
ss -tulnp | grep 5432

# 설정 파일 위치
# CentOS: /var/lib/pgsql/data/postgresql.conf
# Ubuntu: /etc/postgresql/버전/main/postgresql.conf

# 현재 설정 확인
grep listen_addresses /var/lib/pgsql/data/postgresql.conf
# 기본값: listen_addresses = 'localhost'

# 외부 접속 허용으로 변경
vi /var/lib/pgsql/data/postgresql.conf
INI
# 변경 전
listen_addresses = 'localhost'

# 변경 후 — 모든 인터페이스
listen_addresses = '*'

# 또는 특정 IP만
# listen_addresses = 'localhost, 192.168.1.200'
위험 명령어

이 명령은 실행 중인 서비스 상태를 바꿔 순간적인 중단이나 설정 반영 실패를 만들 수 있습니다. 운영 트래픽 영향과 재시작 후 확인 명령을 먼저 준비하세요.

로컬 터미널
# pg_hba.conf에서도 접속 허용 규칙 추가 필요
vi /var/lib/pgsql/data/pg_hba.conf
# 다음 줄 추가 (파일 끝부분에):
# host    all    all    192.168.1.100/32    md5

# PostgreSQL 재시작
systemctl restart postgresql

# 바인딩 확인
ss -tulnp | grep 5432
# tcp LISTEN 0 128 0.0.0.0:5432 0.0.0.0:*

# 외부에서 접속 테스트
psql -h 192.168.1.200 -U postgres -c "SELECT version();"
서비스별 기본 포트와 바인딩 설정 파일 정리

서비스마다 기본 포트와 바인딩 설정 방법이 다릅니다. 자주 마주치는 서비스들을 정리합니다.

로컬 터미널
# 여러 서비스의 바인딩 상태 한번에 확인
echo "=== 데이터베이스 서비스 바인딩 현황 ==="
echo "[MySQL 3306]"
ss -tulnp | grep ':3306' || echo "  → 리스닝 없음"

echo "[PostgreSQL 5432]"
ss -tulnp | grep ':5432' || echo "  → 리스닝 없음"

echo "[Redis 6379]"
ss -tulnp | grep ':6379' || echo "  → 리스닝 없음"

echo "[MongoDB 27017]"
ss -tulnp | grep ':27017' || echo "  → 리스닝 없음"

echo "[Elasticsearch 9200]"
ss -tulnp | grep ':9200' || echo "  → 리스닝 없음"

서비스별 바인딩 설정 요약 — 주요 서비스의 기본 포트와 설정 방법을 한눈에 정리합니다.

서비스기본 포트설정 파일설정 항목
MySQL3306/etc/my.cnfbind-address = 0.0.0.0
PostgreSQL5432postgresql.conflisten_addresses = '*'
Redis6379/etc/redis/redis.confbind 0.0.0.0
MongoDB27017/etc/mongod.confbindIp: 0.0.0.0
Elasticsearch9200/9300elasticsearch.ymlnetwork.host: 0.0.0.0
위험 명령어

이 명령은 실행 중인 서비스 상태를 바꿔 순간적인 중단이나 설정 반영 실패를 만들 수 있습니다. 운영 트래픽 영향과 재시작 후 확인 명령을 먼저 준비하세요.

로컬 터미널
# MongoDB 바인딩 변경 예시
vi /etc/mongod.conf
# net:
#   bindIp: 127.0.0.1     ← 변경 전
#   bindIp: 0.0.0.0       ← 변경 후

systemctl restart mongod

# Elasticsearch 바인딩 변경 예시
vi /etc/elasticsearch/elasticsearch.yml
# network.host: 0.0.0.0
# discovery.type: single-node  (단일 노드인 경우)

systemctl restart elasticsearch

7. 핵심 명령어 요약

목적명령어
모든 리스닝 소켓 확인ss -tulnp
MySQL 바인딩 확인ss -tulnp | grep 3306
Redis 바인딩 확인ss -tulnp | grep 6379
MySQL bind-address 설정 위치/etc/my.cnf 또는 /etc/my.cnf.d/*.cnf
Redis bind 설정 위치/etc/redis/redis.conf
MySQL 재시작systemctl restart mysqld
Redis 재시작systemctl restart redis
방화벽에서 특정 IP만 3306 허용 (CentOS)firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.100" port port="3306" protocol="tcp" accept' --permanent

정리

  • 127.0.0.1 바인딩 = 루프백 전용 → 같은 서버에서만 접근 가능
  • 0.0.0.0 바인딩 = 모든 인터페이스 → 외부에서 접근 가능
  • 외부 접속 필요 시: bind-address = 0.0.0.0 + 방화벽으로 IP 제한
  • MySQL은 바인딩 변경 후 사용자 host 권한도 함께 확인
  • Redis는 0.0.0.0 설정 시 requirepass를 반드시 함께 설정
  • ss -tulnp는 바인딩 주소 확인의 첫 번째 도구

지식 확인

퀴즈 — 5문제

Q1

데몬이 127.0.0.1에 바인딩되었을 때 발생하는 현상으로 올바른 것은?

Q2

`ss -tulnp` 출력에서 `0.0.0.0:3306`이 의미하는 것은?

Q3

MySQL의 바인딩 주소를 변경하는 설정 파일과 지시어로 올바른 것은?

Q4

Redis를 0.0.0.0으로 바인딩한 후 반드시 해야 할 조치는?

Q5

루프백 인터페이스(lo)의 특징으로 올바른 것은?

0 / 5 답변

🧪 실습으로 확인하기

포트는 열렸다는데 왜 안 되지? — ss/netstat/telnet으로 TCP 진단

초급

"포트 8080 열었는데요?"와 "왜 안 돼요?" 사이의 간극을 메우는 실습. ss로 바인딩 상태를 확인하고, telnet/nc으로 원격 연결을 테스트하고, iptables 방화벽을 진단하고, 바인딩 주소(0.0.0.0 vs 127.0.0.1)까지 수정하는 4단계 TCP 포트 진단 플로우를 완성한다.

35📋 4단계💻 직접 환경
실습 시작하기 →

이것도 배워보세요

networking입문 · 45
[Network] NAT 변환과 포트 포워딩(Port Forwarding) 작동 원리
Networking 트랙 계속
docker입문 · 30
[Docker] 백엔드 개발자에게 Docker와 컨테이너 가상화가 필수인 이유
Docker 트랙 시작점