리눅스 서버에 접속하려고 했는데 SSH가 안 되거나, 도메인을 연결했는데 브라우저에서 열리지 않을 때 가장 먼저 확인해야 할 값이 서버 IP입니다. 문제는 관리 화면에 보이는 IP와 서버 안에서 ip addr로 보이는 IP가 서로 다를 수 있다는 점입니다. 이 글은 초보자가 서버 IP 주소를 확인할 때 공인 IP와 사설 IP를 구분하고, 실제 접속 문제에서 어떤 순서로 원인을 좁혀야 하는지 정리한 실무형 점검 문서입니다.
이 글에서 해결할 문제
서버 IP 주소 확인은 단순히 숫자 하나를 찾는 작업처럼 보이지만, 운영 중에는 다음 상황과 자주 연결됩니다.
- SSH 접속 명령어에 어떤 IP를 넣어야 하는지 헷갈리는 경우
- 서버 내부에서는 서비스가 실행 중인데 외부에서 접속되지 않는 경우
- 클라우드 관리 화면의 공인 IP와 리눅스 명령어 결과가 다르게 보이는 경우
- 도메인 A 레코드가 예전 서버 IP를 가리키는지 확인해야 하는 경우
- 재부팅 또는 서버 재생성 후 IP가 바뀌었는지 점검해야 하는 경우
서버 운영에서는 처음에는 서버가 꺼진 문제처럼 보였지만, 실제로는 잘못된 IP를 사용했거나 공인 IP와 사설 IP를 혼동한 경우가 많습니다. SSH 접속 문제도 IP, 포트, 사용자 계정, SSH 키, 방화벽 중 하나만 맞지 않아도 실패할 수 있으므로 IP부터 정확히 분리해서 보는 습관이 필요합니다.
먼저 확인할 핵심 요약
| 확인 대상 | 확인 위치 | 주로 쓰는 상황 | 주의할 점 |
|---|---|---|---|
| 공인 IP | 클라우드 관리 화면, 외부 IP 확인 명령 | SSH 접속, 도메인 연결, 외부 웹 접속 | 서버 재생성 또는 동적 IP 환경에서는 바뀔 수 있음 |
| 사설 IP | 서버 내부의 ip addr 결과 |
내부망 통신, 같은 VPC 안의 서버 간 연결 | 외부 인터넷에서 직접 접속할 수 없는 경우가 많음 |
| 도메인 연결 IP | DNS 조회 결과 | 도메인이 현재 서버를 가리키는지 확인 | DNS 전파 시간 때문에 결과가 늦게 바뀔 수 있음 |
초보자라면 먼저 클라우드 관리 화면에서 공인 IP를 확인하고, 그다음 서버 안에서 내부 IP를 확인한 뒤, 마지막으로 외부에서 실제 접근 가능한지 확인하는 순서가 가장 안전합니다.
실제 서버 운영 중 헷갈리기 쉬운 지점
1. 서버 안에서 보이는 IP가 외부 접속용 IP가 아닐 수 있다
VPS나 클라우드 서버에서는 서버 내부 명령어로 10.x.x.x, 172.16.x.x, 192.168.x.x 같은 주소가 보이는 경우가 있습니다. 이 주소들은 일반적으로 사설 IP 대역입니다. 같은 내부 네트워크에서는 사용할 수 있지만, 집이나 사무실 PC에서 SSH로 바로 접속하는 주소로는 맞지 않을 수 있습니다.
2. 외부 IP 확인 명령은 NAT 이후의 주소를 보여줄 수 있다
서버 안에서 외부 서비스에 접속해 내 IP를 확인하면, 서버가 인터넷으로 나갈 때 사용하는 공인 IP가 표시됩니다. 대부분 외부 접속용 공인 IP와 같지만, 클라우드 NAT, 로드밸런서, 프록시 구성에 따라 다르게 보일 수 있습니다. 따라서 이 값만 믿기보다 클라우드 관리 화면의 네트워크 정보와 함께 비교해야 합니다.
3. 도메인은 맞는데 IP가 예전 값일 수 있다
도메인을 서버에 연결했다면, 브라우저 오류만 보고 서버 문제라고 판단하기 전에 DNS가 현재 공인 IP를 가리키는지 확인해야 합니다. 도메인 설정을 바꾼 직후에는 DNS 캐시나 전파 시간 때문에 조회 위치에 따라 결과가 다르게 나올 수 있습니다.
1단계: 클라우드 관리 화면에서 공인 IP 확인
가장 먼저 서버를 만든 서비스의 관리 화면을 확인합니다. AWS Lightsail, EC2, Vultr, DigitalOcean, Oracle Cloud, Cafe24 VPS 등 서비스마다 메뉴 이름은 다르지만 보통 인스턴스, 서버, 네트워크, IPv4, Public IP 같은 항목에 공인 IP가 표시됩니다.
이 단계에서 함께 확인할 항목은 다음과 같습니다.
- 서버 상태가 실행 중인지
- 공인 IPv4가 할당되어 있는지
- 고정 IP인지, 재시작 후 변경될 수 있는 IP인지
- 접속하려는 서버 이름과 지역이 맞는지
- SSH 포트 또는 보안 그룹에서 접속 포트가 열려 있는지
IP만 복사하지 말고 서버 이름과 함께 기록해 두는 것이 좋습니다. 서버를 여러 대 운영하다 보면 테스트 서버의 IP를 운영 서버로 착각하는 일이 생각보다 자주 생깁니다.
2단계: 리눅스 서버 안에서 IP 확인
서버에 이미 접속할 수 있는 상태라면, 터미널에서 현재 네트워크 인터페이스에 할당된 IP를 확인합니다. Debian/Ubuntu 계열에서는 기본적으로 ip 명령을 사용할 수 있는 경우가 많습니다.
ip addr show
hostname -I
ip routeip addr show는 인터페이스별 주소를 자세히 보여줍니다. hostname -I는 서버에 할당된 IP를 간단히 나열합니다. ip route는 기본 게이트웨이와 어떤 인터페이스를 통해 외부로 나가는지 확인할 때 도움이 됩니다.
출력에서 inet 뒤에 나오는 값이 IPv4 주소입니다. 예를 들어 다음과 비슷한 형태로 보일 수 있습니다.
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
inet 10.0.0.12/24 brd 10.0.0.255 scope global ens3
valid_lft forever preferred_lft forever여기서 10.0.0.12는 사설 IP 대역입니다. 외부 PC에서 SSH 접속 주소로 사용하기보다는 같은 내부망의 다른 서버와 통신할 때 쓰이는 주소일 가능성이 높습니다. 환경에 따라 공인 IP가 인터페이스에 직접 붙어 있는 VPS도 있으므로, 무조건 사설 IP라고 단정하지 말고 관리 화면의 공인 IP와 비교해야 합니다.
3단계: 서버가 밖으로 나갈 때 보이는 IP 확인
서버 내부에서 외부 인터넷으로 나갈 때 어떤 IP로 보이는지 확인하려면 curl을 사용할 수 있습니다. 이 명령은 서버 설정을 변경하지 않고 조회만 합니다.
curl -4 https://ifconfig.me
curl -4 https://api.ipify.org
curl -4 https://icanhazip.com위 명령은 외부 서비스에 접속해 현재 요청의 IPv4 주소를 보여줍니다. 다만 외부 서비스가 일시적으로 응답하지 않을 수도 있고, 회사망이나 프록시, 클라우드 NAT 구성에서는 관리 화면의 공인 IP와 다르게 보일 수 있습니다. 중요한 서버라면 한 곳의 결과만 믿지 말고 관리 화면과 함께 확인하는 편이 좋습니다.
4단계: 외부 PC에서 실제 접속 대상 IP 확인
서버 IP를 확인했다면, 내 PC나 다른 외부 환경에서 해당 IP로 접근 가능한지 확인합니다. SSH 접속을 예로 들면 다음처럼 공인 IP를 사용합니다.
ssh username@203.0.113.10포트를 기본값인 22번이 아닌 다른 값으로 운영 중이라면 -p 옵션을 함께 사용합니다.
ssh -p 2222 username@203.0.113.10SSH 접속이 실패한다고 해서 바로 서버를 재시작하거나 방화벽을 변경하지 않는 것이 좋습니다. 먼저 아래 값을 순서대로 확인합니다.
- 접속 IP가 공인 IP인지
- 사용자 계정명이 맞는지
- SSH 포트가 맞는지
- SSH 키 파일을 사용해야 하는 서버인지
- 클라우드 보안 그룹 또는 방화벽에서 해당 포트를 허용하는지
운영 중에는 접속이 안 된다는 이유로 방화벽 설정부터 바꾸면 원인을 더 헷갈리게 만들 수 있습니다. 방화벽 변경은 접속 포트와 현재 규칙을 확인한 뒤 필요한 범위에서만 진행해야 합니다.
처음 의심하기 쉬운 원인과 실제 원인의 차이
| 증상 | 처음 의심하기 쉬운 원인 | 실제로 자주 확인되는 원인 | 먼저 볼 것 |
|---|---|---|---|
| SSH 접속 실패 | 서버가 꺼짐 | 사설 IP로 접속, 사용자명 오류, 포트 오류, 키 파일 문제 | 공인 IP, 접속 명령어, 포트, 계정명 |
| 도메인 접속 실패 | 웹서버 오류 | DNS A 레코드가 예전 IP를 가리킴 | DNS 조회 결과와 공인 IP 비교 |
| 서버 내부에서는 응답, 외부에서는 실패 | 앱 코드 오류 | 방화벽, 보안 그룹, Nginx 프록시, 포트 미개방 | 내부 curl과 외부 접속 결과 분리 |
리눅스를 오래 다루다 보면 화면에 보이는 오류보다 먼저 접속 경로를 나누어 보는 편이 원인을 좁히기 쉽습니다. 내부에서는 되는지, 같은 서버에서만 되는지, 외부 인터넷에서도 되는지를 분리하면 IP 문제인지 서비스 문제인지 더 빨리 판단할 수 있습니다.
실제로 자주 막히는 상황
상황 1. ip addr에서 본 10.x.x.x 주소로 SSH 접속하는 경우
서버 안에서 확인한 10.0.0.12 같은 주소를 외부 PC의 SSH 명령어에 넣으면 접속이 되지 않을 수 있습니다. 이 주소는 내부망 주소일 가능성이 높기 때문입니다.
상황 2. 서버를 재생성한 뒤 예전 IP로 접속하는 경우
VPS를 삭제 후 다시 만들거나, 고정 IP를 연결하지 않은 상태에서 서버를 재생성하면 공인 IP가 바뀔 수 있습니다. 예전에 메모해 둔 IP로 접속하면 당연히 연결되지 않습니다.
상황 3. 도메인은 맞지만 A 레코드가 다른 서버를 가리키는 경우
도메인 관리 화면에서 A 레코드를 수정했더라도 실제 조회 결과가 즉시 바뀌지 않을 수 있습니다. 또한 루트 도메인과 www 도메인을 각각 따로 설정해야 하는 경우도 있습니다.
원인 분리: 내부 IP, 공인 IP, 도메인을 따로 확인하기
접속 문제가 생겼을 때는 한 번에 모든 설정을 바꾸기보다 아래 순서로 나눠 확인합니다.
- 클라우드 관리 화면에서 현재 공인 IP를 확인한다.
- 서버 내부에서
ip addr show로 인터페이스 IP를 확인한다. - 서버 내부에서
curl -4 https://ifconfig.me로 외부에 보이는 IP를 확인한다. - 도메인을 사용한다면 DNS 조회 결과가 공인 IP와 같은지 확인한다.
- SSH 또는 웹 접속이 안 되면 포트와 방화벽을 별도로 확인한다.
도메인 조회는 다음 명령으로 확인할 수 있습니다. dig가 없다면 Debian/Ubuntu에서 dnsutils 패키지가 필요할 수 있지만, 운영 서버에서는 패키지 설치 전 영향 범위를 확인하는 것이 좋습니다. 로컬 PC에서 실행해도 됩니다.
dig +short example.com
getent hosts example.comexample.com 자리에는 본인의 도메인을 넣습니다. 조회 결과가 현재 서버의 공인 IP와 다르면 DNS 설정이 아직 반영되지 않았거나, 다른 레코드를 보고 있을 수 있습니다.
잘못된 예시
다음은 초보자가 자주 하는 실수입니다. 서버 내부에서 확인한 사설 IP를 외부 접속용으로 그대로 사용하는 경우입니다.
ip addr show
# 출력에서 10.0.0.12를 확인한 뒤 외부 PC에서 실행
ssh ubuntu@10.0.0.12같은 내부망에 있는 서버라면 접속될 수도 있지만, 일반적인 집 또는 사무실 PC에서는 이 주소로 접근할 수 없는 경우가 많습니다. 이때는 서버가 꺼진 것이 아니라 접속 대상 IP가 잘못된 것일 수 있습니다.
수정 예시
수정은 서버 설정을 바로 바꾸는 것이 아니라, 먼저 올바른 공인 IP를 확인해 접속 명령어를 고치는 방식으로 시작합니다.
# 1. 클라우드 관리 화면에서 공인 IP 확인
# 예: 203.0.113.10
# 2. 외부 PC에서 공인 IP로 SSH 접속
ssh ubuntu@203.0.113.10
# 3. 포트가 다르면 포트 옵션 추가
ssh -p 2222 ubuntu@203.0.113.10사용자명은 서버 이미지와 생성 방식에 따라 ubuntu, debian, 직접 만든 사용자명 등으로 다를 수 있습니다. 접속이 실패하면 무작정 반복하기보다 공인 IP, 사용자명, 포트, SSH 키 파일을 하나씩 확인해야 합니다.
수정 후 확인 방법
올바른 IP로 접속한 뒤에는 현재 접속한 서버가 의도한 서버인지 확인합니다. 여러 서버를 운영하면 잘못된 서버에 들어가 작업하는 실수가 생길 수 있습니다.
hostname
whoami
ip addr show
ip route
datehostname은 서버 이름, whoami는 현재 사용자, ip addr show는 내부 IP, ip route는 네트워크 경로를 확인하는 데 사용합니다. date는 서버 시간이 예상과 맞는지 볼 때 도움이 됩니다. 서버 시간대가 다르면 로그 시간을 잘못 해석할 수 있으므로, 접속 문제를 추적할 때 의외로 중요합니다.
웹서비스까지 확인해야 한다면 내부 응답과 외부 응답을 나누어 봅니다.
# 서버 내부에서 로컬 서비스 확인 예시
curl -I http://127.0.0.1
# 외부 PC에서 공인 IP 또는 도메인 확인 예시
curl -I http://203.0.113.10
curl -I http://example.com내부에서는 응답하는데 외부에서만 실패한다면 앱 자체보다 방화벽, 클라우드 보안 그룹, 프록시, DNS 방향을 먼저 확인하는 편이 좋습니다. 방화벽이나 Nginx 설정 변경은 서비스에 영향을 줄 수 있으므로 현재 규칙과 설정 테스트를 먼저 확인한 뒤 진행해야 합니다.
재발 방지 체크리스트
- 서버 생성 직후 공인 IP, 사설 IP, 서버 이름을 함께 기록한다.
- SSH 접속 명령어를 메모할 때 사용자명과 포트도 같이 적어 둔다.
- 고정 IP가 필요한 서버라면 클라우드에서 고정 IP 또는 탄력 IP 설정 여부를 확인한다.
- 도메인을 연결했다면 A 레코드와 현재 공인 IP가 일치하는지 확인한다.
- 서버 재생성, 이전, 복구 후에는 예전 IP를 계속 쓰고 있지 않은지 확인한다.
- 외부 접속 문제는 내부 응답, 공인 IP, DNS, 포트, 방화벽 순서로 분리한다.
- 방화벽이나 웹서버 설정을 바꾸기 전에는 현재 상태를 먼저 확인한다.
- 여러 서버를 운영한다면 작업 전
hostname과whoami로 대상 서버와 사용자를 확인한다.
FAQ
Q1. ip addr에 IP가 여러 개 보이면 어떤 것을 써야 하나요?
외부에서 SSH나 웹으로 접속하려면 보통 공인 IP를 사용합니다. 10.x.x.x, 172.16.x.x, 192.168.x.x처럼 보이는 주소는 사설 IP일 가능성이 높습니다. 다만 클라우드 구성에 따라 다를 수 있으므로 관리 화면의 공인 IP와 비교해 판단하는 것이 안전합니다.
Q2. 서버 안에서 확인한 외부 IP와 관리 화면의 공인 IP가 다르면 문제인가요?
항상 문제라고 볼 수는 없습니다. NAT, 로드밸런서, 프록시, 클라우드 네트워크 구성에 따라 서버가 밖으로 나갈 때 보이는 IP와 외부에서 들어올 때 사용하는 IP가 다를 수 있습니다. SSH 접속이나 도메인 연결 목적이라면 관리 화면의 공인 IP와 DNS 설정을 우선 확인하는 편이 좋습니다.
Q3. 도메인을 새 서버 IP로 바꿨는데 바로 접속되지 않습니다. 무엇을 확인해야 하나요?
먼저 DNS 조회 결과가 새 공인 IP를 가리키는지 확인합니다. 루트 도메인과 www 도메인이 따로 설정되어 있을 수 있고, DNS 전파 시간 때문에 일부 환경에서는 예전 IP가 보일 수 있습니다. DNS가 맞는데도 접속되지 않으면 웹서버 상태, 포트, 방화벽, 클라우드 보안 그룹을 순서대로 확인해야 합니다.