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 -tulnpss -tulnp | grep '127.0.0.1'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로 들어오는 연결만 |
::1 | IPv6 루프백 | 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 명령어로 현재 서버의 모든 리스닝 소켓과 바인딩 주소를 확인합니다.
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part2/exam_8 && cd /tmp/networking/part2/exam_8
ss -tulnp
- 핵심 출력—명령 결과에서 성공/실패를 가르는 값을 먼저 확인합니다
- 대상 식별—IP, 포트, 인터페이스, 프로세스명처럼 다음 조치를 결정하는 필드를 봅니다
- 다음 분기—결과가 기대와 다르면 어느 계층을 이어서 점검할지 정합니다
옵션 설명 — 각 옵션이 바인딩 동작에 미치는 영향입니다.
| 옵션 | 의미 |
|---|---|
-t | TCP 소켓 |
-u | UDP 소켓 |
-l | LISTEN 상태만 |
-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.cnf의bind-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.cnf의bind-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.cnf의bind-address지시어를 편집해야 합니다.
문제 상황을 재현하고 확인하는 과정부터 시작합니다.
# 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
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만 받습니다.
[mysqld]
# 기본값 — 127.0.0.1 또는 아무 설정도 없으면 암묵적 127.0.0.1
bind-address = 127.0.0.1
변경 후 설정 — 외부 접속을 허용하도록 listen_addresses를 수정합니다.
[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
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
# 변경 전
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 ← 성공
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 연결 거부 시 나타나는 에러입니다.
# 외부에서 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
# 외부 바인딩 설정
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 허용
업무 현장에서 자주 발생하는 상황
-
개발 완료 후 스테이징 배포: 개발 환경에서는 같은 서버에 앱+DB가 있어서 127.0.0.1로 잘 됐는데, 스테이징에서 서버를 분리하면서 연결 실패
-
Docker Compose 환경: 같은 Compose 네트워크에 있어도 MySQL이 127.0.0.1에 바인딩이면 다른 컨테이너에서 접속 불가
-
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은 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
# 변경 전
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 " → 리스닝 없음"
서비스별 바인딩 설정 요약 — 주요 서비스의 기본 포트와 설정 방법을 한눈에 정리합니다.
| 서비스 | 기본 포트 | 설정 파일 | 설정 항목 |
|---|---|---|---|
| MySQL | 3306 | /etc/my.cnf | bind-address = 0.0.0.0 |
| PostgreSQL | 5432 | postgresql.conf | listen_addresses = '*' |
| Redis | 6379 | /etc/redis/redis.conf | bind 0.0.0.0 |
| MongoDB | 27017 | /etc/mongod.conf | bindIp: 0.0.0.0 |
| Elasticsearch | 9200/9300 | elasticsearch.yml | network.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는 바인딩 주소 확인의 첫 번째 도구