네트워크
Linux 커널은 소켓, 라우팅, TCP/IP 처리와 네트워크 장치 드라이버를 연결한다. 웹 요청 전체를 커널이 처리하는 것은 아니다. DNS 해석이나 TLS 같은 기능에는 사용자 공간 라이브러리와 애플리케이션 설정도 관여할 수 있다.
연결 실패를 단계별로 나누기
iproute2가 설치된 Linux에서 다음 명령으로 로컬 상태부터 확인한다.
ip -br address
ip route
ss -ltn
첫 번째는 인터페이스 주소, 두 번째는 라우팅 테이블, 세 번째는 listen 중인 TCP 소켓을 보여 준다. 서비스가 127.0.0.1에만 바인딩되어 있다면 다른 호스트에서 직접 연결할 수 없다. 포트가 listen 상태라고 방화벽과 라우팅까지 통과한다는 뜻도 아니다.
원격 서비스의 문제는 이름 해석 → 목적지 경로 → TCP 연결 → TLS → 애플리케이션 응답 순으로 나눠 확인하면 실패 지점을 좁히기 쉽다. curl -v https://example.com/ 같은 요청에서는 인증서 오류와 HTTP 상태 코드를 구분한다. 실제 인증 헤더를 사용하는 요청 로그는 그대로 공유하지 않는다.
컨테이너 안팎의 localhost
네트워크 namespace가 다르면 localhost가 가리키는 네트워크 공간도 다르다. 별도 네트워크의 컨테이너 안에서 127.0.0.1은 보통 그 컨테이너 자신이다. 호스트의 서비스나 다른 컨테이너에 연결하려면 네트워크 구성에 맞는 주소를 사용해야 한다.
LiveSync 구성에서 Nginx와 CouchDB를 같은 호스트의 프로세스로 실행하는지, 각각 컨테이너로 실행하는지에 따라 upstream 주소가 달라지는 이유도 여기에 있다.