127.0.0.1:57573 로컬 호스트 포트 안내 및 문제 해결
간단한 Flask 스크립트를 실행해 보세요. 브라우저에 `http://127.0.0.1:57573`을 붙여넣으세요. 결과는 두 가지입니다. 페이지가 로드되거나, 터미널에 `ECONNREFUSED` 오류와 함께 빨간색 불이 들어오고 브라우저에는 연결이 끊긴 듯한 아이콘이 표시됩니다.
두 결과 모두 불가사의한 것은 아닙니다. 주소는 두 부분으로 구성되어 있는데, 127.0.0.1은 IPv4 루프백 주소이고, 57573은 운영 체제가 높은 포트 풀에서 거의 무작위로 할당한 포트입니다. 이 가이드에서는 두 부분을 모두 자세히 살펴봅니다. 왜 이렇게 많은 로컬 서버가 이러한 포트를 사용하는지 알아보고, 연결이 설정되기 전에 발생할 수 있는 여러 가지 문제점을 하나씩 살펴보겠습니다. 이 가이드를 마치면 서비스를 올바른 인터페이스에 바인딩하는 방법, 실제로 어떤 프로그램이 특정 포트에서 수신 대기 중인지 확인하는 방법, 포트 충돌 및 방화벽 차단을 해결하는 방법, 그리고 로컬 서버를 공용 인터넷에 연결하기 전에 보안을 강화하는 방법을 알게 될 것입니다.
127.0.0.1:57573의 의미를 쉽게 설명하자면?
세 부분으로 구성됩니다. IP 주소 127.0.0.1은 IPv4 루프백 주소입니다. 콜론은 "이 포트에서"라는 의미입니다. 57573은 포트 번호 자체이며, 널리 사용되는 서비스 중 어느 곳도 영구적으로 소유하지 않는 높은 번호 대역에 속합니다.
해당 주소에 연결하면 커널이 패킷을 로컬 컴퓨터로 바로 다시 전송합니다. 네트워크 카드도, 스위치도 필요 없고, 회선을 통한 왕복도 없습니다. 이 주소를 통해 프로세스는 외부 네트워크에 아무것도 노출하지 않고 동일 호스트의 다른 프로세스와 통신할 수 있습니다. 이것이 바로 루프백 주소의 핵심입니다.
이 예약 주소는 대부분의 개발자가 사용하기 전부터 존재해 왔습니다. RFC 1122 3.2.1.3절은 1989년에 127.0.0.0/8 블록 전체, 즉 16,777,216개의 주소를 영구적으로 네트워크에서 사용하지 못하도록 지정했습니다. RFC 6890에 따라 관리되고 RFC 8190에 의해 업데이트되는 IANA IPv4 특수 목적 주소 레지스트리는 동일한 블록을 포워딩 불가능, 전역 라우팅 불가능, 프로토콜에 의해 예약된 주소로 표시합니다. 127.0.0.1에서 수신 대기하는 모든 프로세스는 자체 호스트의 트래픽만 수신합니다. 외부에서 127 소스 주소를 사용하는 모든 패킷은 조용히 차단됩니다. 네트워크 전문가들은 이러한 패킷을 "외계인 패킷"이라고 부릅니다.
`localhost`는 같은 개념을 사람이 이해하기 쉽게 표현한 호스트 이름일 뿐입니다. macOS나 Linux에서는 `/etc/hosts` 파일을, Windows에서는 `C:\Windows\System32\drivers\etc\hosts` 파일을 열어보면 맨 위쪽에 `127.0.0.1 localhost`라는 줄이 있을 겁니다.
루프백 주소: localhost가 사용자 컴퓨터로 연결되는 방식
127.0.0.1이 유명하지만, 그것만이 전부는 아닙니다. 127.0.0.0/8 블록 전체, 즉 1,600만 개가 넘는 모든 주소가 루프백됩니다. 리눅스에서는 127.42.42.42로 핑을 보내도 정상적으로 작동합니다. 대부분의 사용자는 습관적으로 127.0.0.1을 사용하지만, iptables 규칙을 읽거나 보안 강화 이미지를 감사할 때는 더 넓은 블록의 범위도 고려해야 합니다. (수년 전부터 IETF에는 127/8 블록의 대부분을 유니캐스트 용도로 회수하자는 초안이 있었지만 채택되지 않았습니다.)
IPv6 측은 더 간결합니다. RFC 4291에 정의된 하나의 주소, `::1`만 사용합니다. /8 영역도 없고, 여유 공간도 없습니다. 서비스가 `::1`에만 바인딩되면 127.0.0.1로 시도하는 모든 서버는 응답을 받지 못하고, 그 반대의 경우도 마찬가지입니다. 최신 Linux 시스템과 macOS에서는 `localhost`가 두 주소 모두로 해석되므로 브라우저는 일반적으로 `::1`을 먼저 시도하고 실패한 후 `::1`로 대체합니다. 이로 인해 아주 미미하지만 눈에 띄는 지연이 발생합니다. 스크립트 내에서 하나의 주소로 고정하면 이러한 모호성이 사라집니다.
커널은 가상 인터페이스에서 루프백 패킷을 처리합니다. Linux에서는 이를 `lo`라고 부르고, macOS에서는 `lo0`이라고 부릅니다. `ip link show`와 `ifconfig lo0` 명령어를 통해 확인할 수 있습니다. 루프백 패킷도 다른 모든 트래픽을 제어하는 동일한 방화벽 스택의 적용을 받기 때문에, 방화벽 설정을 과도하게 강화하면 로컬 트래픽이 차단될 수 있습니다. 이에 대해서는 몇 섹션에서 더 자세히 설명하겠습니다.
개발의 핵심은 127.0.0.1이 가장 안전한 인터페이스라는 점입니다. 외부에서는 이 인터페이스에 접근할 수 없습니다. 컨테이너와 가상 머신은 호스트와는 별도의 루프백 인터페이스를 사용하는데, 대부분의 개발자들이 Docker 컨테이너 내부의 127.0.0.1 주소로 노트북의 서비스에 자동으로 접속할 수 있을 거라고 기대하는 데서 이 부분을 놓치고 있습니다.
왜 포트 57573을 사용할까요? IANA 포트 번호 범위 설명
포트 57573은 특별한 것이 아닙니다. 운영체제나 프레임워크가 비어있었기 때문에 사용한 것일 뿐입니다. 이렇게 큰 숫자가 자주 나타나는 이유를 이해하려면 IANA가 16비트 포트 공간을 어떻게 분할하는지 살펴봐야 합니다. 전체 체계는 RFC 6335와 IANA 서비스 이름 및 전송 프로토콜 포트 번호 레지스트리에 명시되어 있습니다.
| 범위 | IANA 이름 | 예시 |
|---|---|---|
| 0–1023 | 시스템/잘 알려진 포트 | 22 SSH, 80 HTTP, 443 HTTPS, 53 DNS |
| 1024–49151 | 사용자/등록된 포트 | 3306 MySQL, 5432 Postgres, 8080 alt-HTTP |
| 49152–65535 | 동적/비공개/일시적 | 운영체제에서 자동으로 할당되며, IANA에 등록된 적이 없습니다. |
49152~65535는 IANA 에서 권장하는 임시 포트 범위입니다. 하지만 실제 커널은 종종 이 범위를 벗어납니다. Linux는 기본적으로 32768~60999를 사용합니다(`sysctl net.ipv4.ip_local_port_range`). Windows는 Vista 이후 버전부터 49152~65535를 사용하고 있습니다. XP 시대에는 1025~5000이라는 좁은 범위를 사용했는데, 이 범위는 부하가 걸리면 포트 사용량이 급증하여 유명한 서비스 중단 사태를 일으켰습니다. macOS는 IANA 사양을 따릅니다. 포트 57573은 모든 최신 기본 설정 범위에 속합니다. 바로 이 사실 하나만으로도 개발 로그에서 이 포트가 자주 등장하는 이유를 대부분 설명할 수 있습니다.
Flask에서 `app.run(port=0)`을 실행하거나 Node에서 `server.listen(0)`을 실행하면 운영체제는 로컬 동적 포트 범위에서 사용 가능한 포트를 선택합니다. Linux 노트북의 경우 32768에서 60999 사이의 포트를 사용하게 되는데, 57573 포트도 그중 하나입니다. 자동 포트 할당 기능을 사용하는 도구들도 마찬가지입니다. Vite(2022년에 개발자들이 카페 와이파이를 통해 서버를 노출하는 것을 막기 위해 의도적으로 기본 포트를 127.0.0.1로 설정함), webpack-dev-server, VS Code Live Server, Jupyter, Selenium 드라이버 브리지, Playwright, Node의 `--inspect=0` 디버거 등이 모두 커널에 사용 가능한 높은 포트를 요청하고 할당받은 포트를 사용합니다.
스택 트레이스에 57573이 나타난다면, 거의 항상 간단하지만 정확한 설명이 맞습니다. 어떤 프로세스가 의도적으로 해당 포트에 바인딩되었거나, 프레임워크가 "사용 가능한 포트 아무거나"를 요청했는데 커널이 이 포트를 선택했을 가능성이 높습니다. 57573 포트 자체에 문제가 있는 것은 아닙니다. 대부분의 로컬 테스트 및 개발 프레임워크는 공용 서비스가 해당 포트에 의존하지 않기 때문에 높은 포트 범위를 안전하고 격리된 환경으로 취급합니다.
서버를 127.0.0.1, 0.0.0.0, ::1에 바인딩하는 방법
바인딩 대상을 잘못 선택하면 이상한 버그가 발생합니다. 혼동하지 않아야 할 세 가지 정의가 있습니다.
127.0.0.1은 IPv4 루프백 인터페이스에만 바인딩됩니다. 동일한 컴퓨터에서 모든 IPv4 클라이언트를 통해 접속할 수 있습니다. 외부에서는 절대 접속할 수 없습니다.
::1은 IPv6 루프백 인터페이스만 바인딩합니다. 같은 개념이지만, 동일한 시스템에서 IPv6 클라이언트만 사용할 수 있습니다.
0.0.0.0은 컴퓨터의 모든 IPv4 인터페이스를 바인딩합니다. 동일한 Wi-Fi에 연결된 휴대폰, VPN 연결, 그리고 (포트 포워딩을 통해) 공용 인터넷을 포함하여 사용자의 컴퓨터로 라우팅되는 모든 장치가 해당 컴퓨터에 접근할 수 있습니다.
일상적인 개발 환경에서는 127.0.0.1에 바인딩하세요. 방화벽, VPN 정책, 그리고 의도치 않은 노출로부터 완전히 안전한 유일한 인터페이스입니다. Flask, FastAPI, Express 모두 기본적으로 127.0.0.1을 사용합니다.
제 경험상 사람들이 0.0.0.0으로 향하는 이유는 세 가지입니다. 첫째, LAN을 통해 휴대폰에서 테스트하는 경우, 둘째, Docker 컨테이너 내부에서 테스트하는 경우, 셋째, 잘못된 기본 IP 주소를 복사해서 붙여넣은 튜토리얼을 따라하는 경우입니다. 각각의 경우에 더 안전한 방법이 있습니다. LAN 테스트의 경우, 특정 LAN IP 주소에 바인딩하고 임시 방화벽 규칙을 추가하세요. Docker 테스트의 경우, 컨테이너 내부에서는 0.0.0.0에 바인딩하되 호스트에서는 `docker run -p 127.0.0.1:8080:8080 …` 명령어를 사용하여 IP 주소를 공개하세요. 튜토리얼을 따라하는 경우에는 특별한 이유가 없는 한 0.0.0.0 부분을 무시하고 127.0.0.1을 사용하는 것이 좋습니다.
지루해 보이는 Flask 코드 조각이 안전한 기본값을 보여줍니다.
```
Flask에서 Flask를 가져옵니다.
앱 = Flask(__name__)
@app.route("/")
def index():
"안녕하세요, localhost!"를 반환합니다.
만약 __name__이 "__main__"과 같다면:
앱 실행(호스트="127.0.0.1", 포트=57573)
```
netstat, lsof, ss 명령어를 사용하여 57573번 포트를 검사합니다.
57573 포트에서 무언가가 수신 대기 중인데 무엇인지 전혀 알 수 없습니다. 명령어는 운영체제에 따라 다릅니다. 이 간단한 목록을 외워두면 오랫동안 유용하게 사용할 수 있을 겁니다.
| OS/셸 | 명령 | 메모 | |
|---|---|---|---|
| 리눅스(최신 버전) | `ss -tlnp \ | grep :57573` | netstat을 대체합니다. 루트 권한으로 실행하면 프로세스를 표시합니다. |
| 리눅스(레거시) | `netstat -tlnp \ | grep :57573` | 작은 이미지에는 net-tools가 설치되지 않을 수 있습니다. |
| macOS | `lsof -i :57573` | 리눅스에서도 마찬가지입니다. 프로세스와 사용자 모두 포함됩니다. | |
| 윈도우 명령 프롬프트 | `netstat -ano \ | findstr :57573` | PID 열은 작업 관리자에 매핑됩니다. |
| Windows PowerShell | `Get-NetTCPConnection -LocalPort 57573` | 더 깔끔하고 스크립트 가능한 |
일반적인 Linux 출력:
```
$ ss -tlnp | grep 57573
LISTEN 0 4096 127.0.0.1:57573 0.0.0.0:* users:(("python3",pid=18432,fd=4))
```
왼쪽에서 오른쪽으로 여섯 개의 필드가 있습니다. 상태, 송신 큐, 수신 큐, 로컬 주소, 피어 주소, 그리고 프로세스입니다. 이 경우 PID는 18432입니다. 유닉스에서는 `kill 18432`, PowerShell에서는 `Stop-Process -Id 18432`를 사용하면 됩니다. 포트를 되찾는 것만 원했다면, 이것이 전부입니다.
만약 아무것도 나타나지 않는다면 어떻게 해야 할까요? 아무것도 수신 대기하고 있지 않다는 뜻인데, 이것 자체가 유용한 정보입니다. 브라우저에서 계속해서 보이는 "연결 거부됨" 오류는 대개 바로 이런 상황을 의미합니다. 서버에 문제가 생긴 것입니다. 서버가 시작 시 충돌했거나, 입력한 주소에 연결되지 못했을 가능성이 있습니다.
일반적인 연결 실패 오류 및 그 의미
여섯 가지. 127.0.0.1:57573에서 볼 수 있는 오류 목록은 이게 전부입니다. 오류 문자열을 읽고, 그중 하나를 선택하세요.
`EADDRINUSE`, "주소가 이미 사용 중입니다" 또는 "포트 57573이 이미 할당되었습니다"는 모두 같은 의미입니다. 다른 애플리케이션이 해당 포트를 사용 중입니다. 이전 섹션의 inspect 명령어를 사용하면 어떤 애플리케이션인지 확인할 수 있습니다. 해당 애플리케이션을 종료하거나 서비스에 다른 포트를 사용하세요. netstat이나 lsof 같은 도구를 사용하면 한 줄 명령어로 확인할 수 있습니다.
`ECONNREFUSED`는 좀 더 친근한 표현으로 "연결 거부됨"을 의미하며, TCP가 커널에 진입했지만 아무도 응답하지 않았다는 뜻입니다. 서버가 시작 시 오류가 발생했거나 바인딩에 실패했을 수 있습니다. 서버를 실행한 터미널을 확인해 보세요. 오류 추적 정보가 거기에 있습니다.
`ETIMEDOUT` 및 "연결 시간 초과" 오류는 패킷이 조용히 사라지고 있음을 의미합니다. 127.0.0.1 환경에서는 이러한 현상이 거의 발생해서는 안 됩니다. 만약 발생한다면 방화벽 규칙, VPN 에이전트 또는 엔드포인트 보호 도구가 원인일 가능성이 높습니다. 이러한 요소들을 하나씩 비활성화하고 다시 시도해 보십시오.
루트 권한 없이 1024번 포트보다 낮은 포트에 바인딩하려고 하면 `EACCES`("권한 거부") 오류가 발생합니다. 57573번과 같은 높은 포트를 사용하거나, 바이너리를 루트 권한으로 실행하십시오. 세 번째 옵션은 존재하지 않습니다.
`EAI_NONAME` 및 기타 DNS 오류는 호스트 이름이 확인되지 않았음을 의미합니다. hosts 파일은 `localhost`를 127.0.0.1로 매핑해야 합니다. VPN 클라이언트가 이 설정을 재정의했거나 시스템 관리자가 오류가 있는 이미지를 배포했을 수 있습니다. hosts 파일을 열고 `127.0.0.1 localhost`가 주석 처리되지 않은 첫 번째 줄인지 확인하십시오.
마지막으로, 좀 교묘한 문제인데요. 서버가 정상적으로 종료된 후 커널은 소켓을 약 2분 동안 TIME_WAIT 상태로 유지합니다. 서버를 빠르게 재시작하면 아무도 수신 대기 중이 아닌데도 "주소가 이미 사용 중입니다"라는 메시지가 표시됩니다. 해결 방법은 세 가지입니다. 기다리거나, 바인딩 시 `SO_REUSEADDR`를 설정하거나, 다른 포트로 변경하는 것입니다. 대부분의 경우 포트를 변경하죠.
오류 문자열을 읽고, 해당 버킷을 선택하고, 수정 사항을 적용합니다. 전체 과정은 보통 1분 이내에 완료됩니다.
포트 57573을 차단하는 방화벽 설정
루프백 트래픽은 이론상으로는 항상 허용됩니다. 하지만 실제로는 방화벽 규칙 때문에 허용되지 않는 경우가 있습니다. 2026년에 흔히 발생하는 문제점들은 다음과 같습니다.
- macOS 애플리케이션 방화벽에서 "수신 연결 차단" 설정을 엄격으로 변경하십시오. 시스템 설정 → 네트워크 → 방화벽에서 포트 57573을 소유하는 실행 파일을 허용 목록에 추가하십시오.
- Windows Defender 방화벽 프로필이 일치하지 않습니다. 새 개발자 도구에서 액세스 허용 여부를 묻는 메시지가 나타납니다. 무심코 '취소'를 클릭하면 방화벽이 조용히 차단합니다. `wf.msc`를 열고 거부 규칙을 삭제한 다음, 다음번에 메시지가 나타나면 허용하세요.
- Linux ufw 또는 iptables의 기본 정책이 강화된 경우입니다. `ufw status verbose` 명령은 규칙 목록을 보여줍니다. `ufw allow from 127.0.0.1` 명령은 루프백 인터페이스를 명시적으로 엽니다. 대부분의 배포판은 기본적으로 `lo` 인터페이스를 허용하지만, 일부 강화된 이미지에서는 허용하지 않습니다.
- 기업 VPN 또는 제로 트러스트 에이전트가 트래픽을 가로채고 있습니다. 일부 에이전트는 로컬 연결을 사용자 공간 리스너를 통해 프록시하고 루프백 연결을 몰래 변조합니다. 이를 확인하려면 에이전트를 1분 동안 비활성화해 보세요.
- 바이러스 백신 또는 엔드포인트 보호 제품입니다. EDR 제품은 화이트리스트에 추가하기 전까지 높은 포트에 바인딩되는 개발 바이너리를 차단하는 경우가 있습니다.
관리되는 기업 환경에서는 적어도 이 중 하나는 발생할 것으로 예상됩니다. 진단 절차는 동일합니다. 방화벽 설정을 확인한 다음 서버를 시작한 동일한 셸에서 `curl http://127.0.0.1:57573`을 실행합니다. Curl은 작동하지만 브라우저에서 오류가 발생하는 경우, 잘못된 인터페이스(대개 `::1` 대신 127.0.0.1)에 접속하고 있거나 개인 네트워크 액세스 정책이 적용되고 있는 것입니다. Curl도 실패하는 경우, 커널이나 방화벽이 패킷이 코드에 도달하기 전에 차단하고 있는 것입니다. 웹 개발자와 네트워크 관리자는 증상이 동일해 보이기 때문에 내부 위키에서 이러한 해결 방법을 공유합니다.
Docker, WSL 및 GitHub Codespaces의 로컬 호스트
localhost가 예상대로 작동하지 않는 세 가지 경우.
먼저 Docker에 대해 설명하겠습니다. 컨테이너 내부에서 127.0.0.1은 컨테이너의 루프백 주소입니다. 사용자의 노트북 주소가 아닙니다. 따라서 노트북에서 127.0.0.1:57573 주소로 서비스를 실행하더라도 컨테이너는 동일한 주소로 해당 서비스에 접근할 수 없습니다. 절대로 불가능합니다. 호스트 게이트웨이는 다른 곳에 있습니다. Mac과 Windows에서는 `host.docker.internal`에, Linux에서는 브리지 IP 주소에 있습니다. 반대 방향(컨테이너 서비스, 호스트 호출자)으로 접근하려면 `-p` 플래그가 필요합니다. `docker run -p 127.0.0.1:57573:57573 my-image`와 같이 입력합니다. `-p`를 제거하면 해당 포트는 컨테이너 외부에서는 존재하지 않게 됩니다.
WSL2는 독특한 특징을 가지고 있습니다. 미러링 네트워킹 모드(Windows 11 22H2 이상 버전에서 `[wsl2] networkingMode=mirrored` 명령어를 통해 활성화 가능)는 호스트의 네트워크 스택을 WSL VM과 공유합니다. 이 모드에서는 WSL 내부의 127.0.0.1:57573 주소에 있는 서비스가 Windows에서도 동일한 주소로 응답합니다. 기본 NAT 모드는 포트 포워딩을 지원하지만, `localhost` 문자열에 대해서만 지원하며, 127.0.0.1이라는 실제 주소에 대해서는 항상 지원하지는 않습니다. 또한, Microsoft WSL #40169로 추적되는 알려진 버그가 있습니다. 미러링 모드는 높은 포트 범위를 조용히 잠급니다. 이로 인해 127.0.0.1에 대한 바인딩 시도가 `WinError 10013` 오류와 함께 실패하며, Python은 이를 `PermissionError`로 보고합니다. Windows에서 특정 포트에 바인딩이 되지 않는 경우, 이 문제를 먼저 확인해 보세요.
GitHub Codespaces와 VS Code Remote SSH는 정반대의 방향으로 작동합니다. 포트를 자동으로 포워딩해 줍니다. Codespaces 내에서 127.0.0.1:57573으로 서버를 시작하면 에디터가 터널을 열어 해당 포트를 고유한 github.dev URL로 노출합니다. 노트북에서 연 브라우저 탭은 127.0.0.1이 아닌 이 github.dev URL로 접속하고, 요청은 터널을 통해 작업 공간으로 다시 전달됩니다.
엔드포인트 이름은 동일해 보이지만, 패킷이 실제로 이동하는 경로는 각 환경에서 완전히 다릅니다. 어떤 환경에 있는지 파악하는 데 5분만 투자하면 "연결 거부됨" 메시지를 20분 동안 쳐다보는 수고를 덜 수 있습니다.
로컬 환경에서 HTTPS 사용: 안전한 로컬 개발을 위한 모범 사례
최신 브라우저와 많은 API는 로컬 개발 환경에서도 HTTPS를 요구합니다. 서비스 워커, 위치 정보, 클립보드 API, '보안'으로 표시된 쿠키 등은 모두 일반 HTTP로는 작동하지 않습니다. 단, 브라우저에서 이미 보안 컨텍스트로 처리하는 127.0.0.1은 예외입니다. 이 예외는 대부분의 일반적인 개발 환경에 적용됩니다. 그 외의 모든 경우에는 로컬에서 TLS를 사용하는 것이 좋습니다.
가장 깔끔한 도구는 Filippo Valsorda가 작성한 mkcert입니다. `mkcert -install` 명령으로 한 번 실행한 다음, `mkcert localhost 127.0.0.1 ::1`을 실행하면 `localhost+2.pem` 형식의 인증서와 키가 생성됩니다. 개발 서버에서 이 두 파일을 인증서와 키로 지정하세요. 브라우저에는 경고 없이 깔끔한 자물쇠 아이콘이 표시되는데, 이는 mkcert가 로컬 루트 CA를 시스템과 Firefox 신뢰 저장소에 설치했기 때문입니다. Let's Encrypt는 검증할 도메인이 없기 때문에 `127.0.0.1`에 대한 실제 인증서를 발급할 수 없으므로 로컬 CA를 사용하는 것이 일반적인 해결책입니다.
알아두면 유용한 몇 가지 다른 패턴은 다음과 같습니다.
- 자동화된 테스트를 위해 IP 주소를 `127.0.0.1.nip.io`와 같은 실제 호스트 이름으로 변환하는 매직 DNS 서비스(`nip.io`, `sslip.io`, `traefik.me`, `localhost.direct`)를 지정하세요. Let's Encrypt 또는 ZeroSSL에서 이러한 인증서를 발급받을 수 있으며, `localhost.direct`는 미리 발급된 와일드카드 인증서도 제공합니다.
- 서비스를 0.0.0.0이 아닌 127.0.0.1에 바인딩해야 인증서(`127.0.0.1`을 포함)가 실제로 일치합니다.
- 개발 인증서는 Git에 저장하지 마세요. `mkcert` 명령어는 기본적으로 개발 인증서를 작업 디렉터리에 저장합니다. 따라서 해당 인증서 쌍을 `.gitignore` 파일에 즉시 추가해야 합니다.
- 로컬 CA를 몇 달에 한 번씩 교체하십시오. `mkcert -uninstall` 명령으로 완전히 삭제할 수 있습니다.
- 기업 MITM 프록시 뒤에 있는 경우, 프록시가 인증서를 교체한다는 점을 감안해야 합니다. 사용하는 도구가 지원하는 경우 `127.0.0.1`에서 프록시를 비활성화하십시오.
브라우저에는 알아두면 유용한 특별한 규칙이 있습니다. W3C 보안 컨텍스트 사양에 따르면 `http://127.0.0.1`, `http://localhost`, `http://[::1]`은 "잠재적으로 신뢰할 수 있는 주소"로 간주되어 HTTPS 페이지가 혼합 콘텐츠 차단 없이 해당 주소에 접근할 수 있습니다. 이 예외 조항은 특히 로컬 개발 환경을 위해 마련된 것입니다.
로컬호스트는 개발자들이 흔히 생각하는 것처럼 보안 경계가 아닙니다. 악성 웹사이트가 DNS 리바인딩을 통해 임의의 웹사이트에서 로컬호스트에 접근하도록 속일 수 있습니다. 이 경우 공격자 페이지의 JavaScript가 원래 웹사이트의 DNS에 연결된 로컬 서비스와 통신할 수 있게 됩니다. 2019년 Zoom CVE(CVE-2019-13450)가 대표적인 사례입니다. Zoom은 macOS의 `localhost:19421`에 숨겨진 웹 서버를 설치하여 회의 링크를 클릭하면 데스크톱 앱이 실행되도록 했고, 어떤 웹사이트든 이 서버에서 데이터를 가져와 사용자를 강제로 카메라가 켜진 상태로 회의에 참여시킬 수 있었습니다. 약 400만 대의 Mac과 동일한 엔진을 사용하는 13개의 화이트 라벨 클라이언트가 영향을 받았습니다. 2025년 말에 출시된 Chrome 142에서는 기존의 개인 네트워크 접근(Private Network Access) 기능을 로컬 네트워크 접근(Local Network Access)으로 대체했습니다. 이제 공개 페이지는 루프백 또는 개인 주소에 접근하기 전에 명시적인 권한 요청 메시지를 표시해야 합니다. 이는 NCC 그룹의 Singularity가 자동화했던 대부분의 공격 기법을 무력화합니다. 2025년 Straiker 보안 권고에서는 로컬에서 실행되는 모델 컨텍스트 프로토콜(MCP) 서버를 대상으로 하는 동일한 공격에 대해 기술했는데, 개발자들이 루프백에서 더 많은 LLM 에이전트를 실행함에 따라 이러한 공격이 빠르게 확산되고 있습니다. 개발 API에서 127.0.0.1에만 바인딩하고, 인증을 요구하고, `Origin` 헤더를 확인하고, 와일드카드 CORS를 사용하지 않도록 하세요. 이 네 가지 습관을 통해 대부분의 공격을 방지할 수 있습니다.
문제 해결 팁 및 빠른 진단 체크리스트
127.0.0.1:57573이 응답하지 않을 경우, 더 복잡한 마법을 의심하기 전에 다음 간단한 목록을 확인해 보세요.
1. 서버가 실제로 실행 중인지 확인하십시오. 서버를 실행했던 터미널 창을 살펴보세요. 만약 서버가 충돌했다면, 스택 트레이스가 거기에 표시될 것입니다.
2. 0.0.0.0 또는 ::1 단독이 아닌 127.0.0.1에 바인딩되었는지 확인하십시오. 대부분의 프레임워크는 시작 시 바인딩 주소를 출력합니다. 해당 줄을 확인하십시오.
3. 같은 셸에서 `curl -v http://127.0.0.1:57573`을 실행해 보세요. curl이 작동하나요? 그렇다면 문제는 서버가 아니라 브라우저에 있습니다.
4. 포트 소유자를 확인합니다. Linux: `ss -tlnp | grep :57573`. macOS: `lsof -i :57573`. Windows: `netstat -ano | findstr :57573`.
5. 잘못된 프로세스가 소유권을 가지고 있나요? 해당 프로세스를 종료한 다음 서버를 재시작하세요.
6. 아무것도 수신 대기하지 않나요? 시작 로그를 확인해 보세요. `EACCES`는 권한 있는 포트를 의미합니다. `EADDRINUSE`는 일반적으로 오래된 TIME_WAIT를 의미합니다.
7. IPv6 형식을 시도해 보세요. `curl http://[::1]:57573`. `127.0.0.1` 또는 `::1` 중 하나만 작동하고 다른 하나는 작동하지 않으면 서비스는 단일 스택입니다.
8. 다른 포트를 사용해 보세요. `--port 12345` (또는 원하는 포트)를 전달하고 재부팅하세요. 새 포트에서 작동하나요? 그렇다면 포트 충돌이 발생한 것입니다.
9. VPN, 안티바이러스 및 엔드포인트 에이전트를 1분 동안 종료하십시오. 57573 포트가 응답하면 해당 프로그램 중 하나가 트래픽을 과도하게 처리하고 있었던 것입니다.
10. 재부팅하거나 최소한 네트워크 인터페이스를 재시작하십시오. 거의 해결책이 되지 않습니다. 다른 어떤 방법으로도 해결되지 않을 때, 오래된 소켓과 방화벽 상태 오류를 해결하는 데 도움이 될 수 있습니다.
대부분의 개발 문제에서 처음 네 가지 문제 해결 단계를 통해 연결 실패의 원인을 파악할 수 있습니다. 나머지 단계는 IPv6 불일치, 오래된 소켓 또는 악의적인 방화벽 계층으로 인해 실제 오류가 발생하는 경우와 같이 매우 특수한 상황을 다룹니다. 오류 메시지를 읽은 다음 목록을 순서대로 진행하세요.
Plisio 관련 참고 사항입니다. 암호화폐 결제 처리기의 웹훅을 통합할 때 게이트웨이는 POST 요청을 보낼 수 있는 공개 URL이 필요합니다. Plisio 인보이스는 API 페이로드에 `callback_url`을 허용하며, 시스템은 해당 엔드포인트로 상태 업데이트를 POST합니다. 127.0.0.1:57573에 있는 로컬 서버는 공용 인터넷에서 접근할 수 없으므로, 일반적인 해결 방법은 터널을 사용하는 것입니다. 2026년 기준으로 일반적으로 사용되는 터널로는 ngrok(개인용 월 8달러, 프로용 월 20달러), Cloudflare Tunnel(제로 트러스트 환경에서 최대 50명까지 무료), Tailscale Funnel(개인용 무료, 유료 팀용 월 6달러부터) 등이 있습니다. 각 터널은 공개 호스트 이름을 받아 사용자의 노트북 서버인 127.0.0.1:57573으로 트래픽을 전달합니다. Plisio의 Python, PHP 및 Node SDK에는 정렬된 JSON 본문에 대한 HMAC-SHA1 `verify_hash`를 검증하는 `validate_callback` 헬퍼가 포함되어 있으므로 터널이 설정되면 개발 환경과 프로덕션 환경에서 동일한 핸들러가 동일하게 작동합니다.
