하나의 홈 서버에서 두 개의 리버스 프록시가 80번 및 443번 포트를 공유할 수 있나요?

동일한 IP와 프로토콜을 동시에 사용할 수는 없습니다. 단, 하나의 프록시가 단일 진입점이 되어 선택한 트래픽을 다른 프록시로 전달하거나, 각각 다른 IP에 바인딩하는 경우는 예외입니다.

한 시스템에서 두 프록시 컨테이너가 서로 다른 앱 스택을 위해 호스트 포트 80과 443을 모두 게시하면 이는 실제 호환성 문제가 됩니다. 먼저 일회용 경로나 계정으로 시작하고, 이전에 작동하던 상태를 유지하며, 일회성 연결 테스트가 아니라 원래 워크로드를 기준으로 설계를 판단하세요.

공유 리소스를 누가 소유하는지 확인하기

지원되는 방식은 IP-포트 조합마다 하나의 리스너를 두고 그 뒤에서 라우팅하는 것입니다. 충돌하는 방식은 동일한 소켓을 두 개의 독립 리스너가 차지하려고 경쟁하는 것입니다. 어느 쪽이든 변경하기 전에 버전, 식별 정보, 주소, 마운트 경로, 권한 및 현재 관찰 가능한 상태를 기록하세요.

관련 소켓 바인딩 규칙은 첫 번째 호환성 경계를 정의합니다. 이를 사용해 주장을 제한한 다음, 문서에 설명된 기능이 전체 설계가 작동한다는 증거라고 간주하지 말고 이 정확한 홈 서버에서 동일한 동작을 확인하세요.

테스트 전에 판단 기준을 작성하세요. 성공하려면 의도한 프런트 프록시만 각 공용 소켓을 소유하고 모든 호스트 이름이 예상 인증서와 함께 올바른 업스트림에 도달해야 합니다. 실패에는 시작 시 address in use가 보고되거나, 트래픽이 잘못된 프록시에 도달하거나, TLS가 다른 사이트의 인증서로 종료되는 경우가 포함됩니다. 이렇게 해야 부분적인 연결이나 정상적인 명령 종료를 종단 간 호환성으로 잘못 해석하지 않을 수 있습니다.

한 번에 하나의 리스너 또는 라우팅만 변경하기

하나의 통제된 판별 요소를 사용하세요. 현재 리스너를 나열하고, 각 프록시를 서로 다른 테스트 IP에 바인딩하거나 하나를 다른 프록시 뒤로 이동한 다음 Host, SNI, WebSocket 및 인증서 라우팅을 테스트하세요. 변경된 구성 요소만 가능한 원인이 되도록 클라이언트, 워크로드, 파일 집합, 계정 및 타이밍을 일정하게 유지하세요.

게시된 포트 동작을 사용해 이 경로에서 중요한 두 번째 관찰을 선택하세요. 트랜잭션의 양쪽을 모두 기록하세요. 리졸버 또는 경로, 협상된 프로토콜, 프로세스 식별 정보, 종료 상태, 지연 시간, 전송된 바이트 및 복구 이벤트를 포함해야 합니다.

제목에 명시된 수명 주기 이벤트(재생성, 재연결, 재마운트, 재시작, 장애 조치 또는 클라이언트 변경) 후에 테스트를 반복하세요. 이전 소켓, 캐시 또는 자격 증명이 유지되는 동안에만 작동하는 설계는 통과한 것이 아닙니다.

ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'

관찰 가능한 라우팅 증거로 판단하기

통과: 의도한 프런트 프록시만 각 공용 소켓을 소유하고 모든 호스트 이름이 예상 인증서와 함께 올바른 업스트림에 도달합니다. 이 상태를 만든 정확한 버전과 토폴로지를 저장하세요. 결론은 프로토콜의 모든 구현이 아니라 해당 조건에 적용되기 때문입니다.

실패: 시작 시 address in use가 보고되거나, 트래픽이 잘못된 프록시에 도달하거나, TLS가 다른 사이트의 인증서로 종료됩니다. 두 주요 경로 중 하나에 책임이 있다고 선언하기 전에 DNS, MTU, 식별 정보, 방화벽 상태, 스토리지 지연 시간 및 캐시된 세션과 같은 공유 종속성을 확인하세요.

예외: 두 번째 공용 바인딩을 중지하고, 마지막으로 작동한 리스너를 복원한 다음, 하나의 진입점 또는 서로 다른 호스트 주소를 선택하세요. 반복 가능한 관찰을 통해 어떤 경계가 실패했는지 확인하기 전에는 권한을 확대하거나, 원본 데이터를 삭제하거나, 전송 보안을 약화하거나, 작동 중인 스토리지를 교체하지 마세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

프로덕션 트래픽이 돌아오기 전에 격리 상태 재확인하기

관찰된 경로에 맞는 조치만 적용한 다음 원래 워크로드를 다시 실행하세요. 두 번의 관련 수명 주기와 예상되는 동시 부하에서 의도한 프런트 프록시만 각 공용 소켓을 소유하고 모든 호스트 이름이 예상 인증서와 함께 올바른 업스트림에 도달할 때만 설계를 유지하세요.

전용 프록시 네트워크를 사용해 가장 가까운 종속 워크플로를 확인하세요. 새 설계가 활성화된 동안 해당 워크플로의 액세스, 타이밍 및 복구 동작이 변하지 않아야 합니다.

시작 시 address in use가 보고되거나, 트래픽이 잘못된 프록시에 도달하거나, TLS가 다른 사이트의 인증서로 종료되면 중지하고 저장된 상태로 돌아가세요. 다른 우회 방법을 추가하기보다 타임스탬프, 정확한 버전, 경로 또는 마운트 증거 및 최소 재현 사례를 포함해 에스컬레이션하세요.

리버스 프록시 DNS 재정의와 결과를 교차 확인하여 위험이 다른 네트워크, 식별 정보, 백업 또는 스토리지 계층으로 단순히 이동하지 않았는지 확인하세요.

두 리버스 프록시가 포트를 소유하는 경우, 한정된 답변은 따라서 서두의 판단이지 무조건적인 긍정이 아닙니다. 관찰 가능한 통과 상태가 승인 기준선이고, 실패 상태가 롤백 기준선입니다.

FAQ

SO_REUSEPORT를 사용하면 관련 없는 프록시가 443을 공유할 수 있나요?

독립적인 프록시를 위한 안전한 호스트 이름 라우팅 설계가 아닙니다. 하나의 TLS 진입점 또는 별도의 IP를 사용하세요.

한 프록시가 TLS를 두 번째 프록시로 전달할 수 있나요?

SNI를 기반으로 라우팅하고 다운스트림 프록시가 해당 호스트 이름의 인증서 종료를 담당한다면 가능합니다.

IPv4와 IPv6 리스너가 충돌하나요?

듀얼 스택 소켓 동작과 바인드 주소에 따라 충돌할 수 있습니다. 두 프로토콜 패밀리를 명시적으로 확인하세요.