localhost는 열리는데 다른 주소는 안 열립니다: 바인딩 비교 실습

웹서버가 실행 중이고 localhost에서는 페이지도 보이는데, 다른 기기에서는 연결되지 않을 수 있습니다. 그때 첫 확인 대상 중 하나가 바인딩 주소입니다. 앱이 이 컴퓨터의 어떤 주소로 들어오는 요청을 받을지 정하는 설정입니다.

같은 응답을 주는 서버 두 개를 비교했습니다

2026년 10월 23일 임시 HTTP 서버를 하나씩 띄웠습니다. 처음에는 127.0.0.1, 다음에는 0.0.0.0에 바인딩했습니다. 사용 중인 포트를 건드리지 않도록 운영체제가 빈 포트를 배정하게 하고, 각 시험이 끝나면 서버를 종료했습니다.

127.0.0.2도 이 Linux 환경의 루프백 주소입니다. 이 시험은 휴대전화나 외부 인터넷 접속 시험이 아닙니다. 다른 주소에 대한 수신 범위가 달라지는 점만 확인합니다. 실제 내부망 접속에는 서버 IP, 방화벽, 기기 간 통신 조건도 영향을 줍니다.

바인딩 비교 실습 코드를 받은 뒤 python3 bind-address-demo.py로 실행하면 위 결과를 직접 확인할 수 있습니다. 외부 API나 실제 사이트의 데이터는 사용하지 않습니다.

내 서버에서는 ss로 기다리는 주소를 봅니다

ss -ltn 'sport = :3001'

이 사이트는 3001번 포트를 사용하지만 자신의 포트로 바꿔 확인합니다. 출력이 없다면 그 환경에서 해당 포트를 기다리는 TCP 소켓을 찾지 못한 것입니다. 앱 실행 오류부터 확인하세요. 옵션 설명은 ss 매뉴얼에서 볼 수 있습니다.

0.0.0.0은 방문자에게 보내는 주소가 아닙니다

다른 기기에는 http://서버의실제IP:포트 또는 공개 도메인을 알려줍니다. 휴대전화에 localhost를 입력하면 휴대전화 자신의 서버를 찾습니다. 앱이 HOST 환경변수를 읽는 프로젝트라면 바인딩을 바꾸고 재시작할 수 있지만, 프로젝트마다 설정 이름과 적용 방식은 다릅니다.

터널이나 프록시가 같은 PC에서 대신 접속하는 구조라면 앱을 127.0.0.1로 두어도 됩니다. 모든 서버를 무조건 0.0.0.0으로 바꾸는 것이 해결책은 아닙니다. 어느 프로그램이 앱으로 연결하는지부터 확인합니다.

한 번에 한 구간씩 넓혀봅니다

1. 서버 PC에서 http://127.0.0.1:포트로 응답을 확인합니다.
2. 직접 내부망 접속이 필요한 구성이라면 같은 네트워크의 기기에서 내부 IP와 포트로 확인합니다.
3. 공개 도메인으로 열고, 프록시나 터널이 앱의 실제 포트를 가리키는지 확인합니다.
4. 최종 확인은 서버 밖의 별도 네트워크에서도 진행합니다.

로컬부터 실패하면 실행 상태와 포트, 내부망에서만 실패하면 바인딩·방화벽·네트워크 분리 설정을 봅니다. 도메인에서 502가 나오면 프록시가 앱에 연결할 수 있는지 확인합니다. 같은 PC에서 공개 주소를 열었다는 사실만으로 모든 외부 기기 접근이 검증되지는 않습니다.

이 실습에서 바꾼 것은 임시 서버의 바인딩 한 가지였습니다. 자신의 환경에서도 설정을 하나 바꿀 때마다 같은 주소로 다시 확인하고 결과를 적어보세요. 무엇이 달라졌는지 알아야 다음 접속 장애에서도 같은 순서로 판단할 수 있습니다.