리버스 프록시를 재시작하면 셀프 호스팅 앱 하나의 모든 세션이 무효화되는 이유는 무엇인가요?

리버스 프록시를 재시작했을 때 모든 사용자가 로그아웃되는 것은 해당 애플리케이션이 사용하는 세션 상태가 함께 변경되거나 손실되거나 다른 곳으로 라우팅될 때뿐입니다.

일반적인 프록시는 애플리케이션 세션을 직접 관리하지 않고 쿠키를 전달하므로, 프록시만 재시작한다고 해서 모든 로그인이 무효화되지는 않습니다. 실제 원인은 인증 게이트웨이 재시작, 쿠키 서명 비밀 키 재생성, 메모리 내 세션 캐시, 백엔드 복제본 변경 또는 프록시와 함께 앱을 재시작하는 Compose 종속성일 수 있습니다. 쿠키 속성을 변경하거나 사용자에게 다시 로그인하도록 하기 전에 어떤 구성 요소가 세션을 발급하고 검증하는지 확인하세요.

프록시와 함께 재시작된 서비스 확인

제어된 프록시 재시작을 한 번 수행하기 전후에 리버스 프록시, 인증 서비스, 애플리케이션, 캐시, 데이터베이스의 컨테이너 ID, 시작 시간, 재시작 횟수, 상태 이벤트 및 로그를 기록하세요.

Docker Compose는 종속성이 재시작 전파를 사용하도록 명시적으로 구성된 경우 종속 서비스를 재시작할 수 있습니다. 공식 시작 순서 안내에서는 프록시 재시작이라고 설명한 명령이 인증 또는 애플리케이션 컨테이너를 교체하거나 재시작할 수 있는 이유를 설명합니다.

새 시작 시간을 기록한 것이 프록시뿐이라면 프록시가 관리하는 인증, 라우팅 및 쿠키에 집중하세요. 앱, 캐시 또는 인증 게이트웨이도 재시작되었다면 먼저 세션 지속성과 비밀 키를 점검하세요.

로그인 쿠키를 발급한 계층 확인

재시작하기 전에 쿠키 이름, 도메인, 경로, Secure, HttpOnly, SameSite, 만료 시간 및 쿠키를 설정하는 주체가 애플리케이션인지 인증 게이트웨이인지 기록하세요.

MDN은 쿠키의 범위와 속성이 브라우저가 쿠키를 전송하는 위치를 결정한다고 설명하지만, 이러한 속성만으로는 어떤 백엔드가 해당 값을 검증하는지 알 수 없습니다.

로그인 요청과 재시작 후 첫 번째 요청의 응답 헤더를 비교하세요. 쿠키가 누락되었다면 브라우저 범위 문제이고, 변경되지 않은 쿠키를 서버가 거부한다면 상태 손실, 키 변경 또는 다른 백엔드가 원인일 수 있습니다.

인증 게이트웨이가 세션 비밀 키를 재생성했는지 확인

인증 게이트웨이의 비밀 키 출처, 파일 마운트, 환경 변수, 컨테이너 재생성 여부 및 생성된 구성을 점검하세요. 비밀 값 자체를 노출하지 않고 재시작 전후의 값 출처를 비교하세요.

Authelia는 세션 비밀 키로 저장된 세션 데이터를 암호화한다고 문서화하고 있으므로, 해당 비밀 키가 변경되거나 손실되면 서비스가 이전에 생성된 세션을 읽을 수 없습니다.

세션 비밀 키는 컨테이너가 시작될 때마다 생성하지 말고, 지속적인 비밀 키 파일이나 관리형 비밀 저장소에 보관하세요. 키를 교체할 때는 로그아웃 기간을 문서화하고 계획적으로 진행하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

메모리 내 세션 저장소 배제

애플리케이션이 세션을 프로세스 메모리, 로컬 캐시, Redis, 데이터베이스 또는 서명된 클라이언트 쿠키 중 어디에 저장하는지 확인하세요. 로그아웃이 발생한 시점과 세션 저장소 프로세스의 가동 시간을 비교하세요.

Django는 캐시 전용 세션 백엔드가 캐시 재시작 또는 제거 시 세션 데이터를 잃을 수 있으며, 이로 인해 세션 데이터가 사라질 때 사용자가 로그아웃된다고 경고합니다.

프록시 스택에 캐시 컨테이너가 포함되어 있다면 애플리케이션 컨테이너가 계속 실행 중이어도 해당 스택을 재시작하면서 세션이 삭제될 수 있습니다. 로그인 연속성이 중요하다면 지속형 캐시 구성이나 데이터베이스 기반 대체 저장소를 사용하세요.

재시작 전후 애플리케이션 서명 키 비교

애플리케이션의 세션 서명 또는 암호화 키 출처를 확인하고, 키가 지속적으로 저장되는지, 예상한 환경 변수 파일에서 로드되는지 또는 시작 시 생성되는지 파악하세요.

Flask는 SECRET_KEY로 세션 쿠키에 서명하므로, 브라우저가 기존 쿠키를 계속 전송하더라도 이 키를 교체하면 기존 서명 쿠키가 무효화됩니다.

이 문제를 해결하기 위해 서로 관련 없는 애플리케이션 간에 하나의 비밀 키를 공유하지 마세요. 각 앱에 안정적인 비밀 키를 할당하고 백업에 필수적인 구성으로 안전하게 보호하며, 이미지를 다시 생성해도 키가 유지되는지 확인하세요.

고정 세션과 백엔드 복제본 변경 확인

백엔드 복제본, 각 복제본의 세션 저장소 및 프록시의 로드 밸런싱 정책을 나열하세요. 동일한 사용자의 요청이 다른 복제본으로 전달되어도 로그인 상태가 유지되는지 테스트하세요.

Traefik의 고정 세션 구성은 클라이언트를 하나의 백엔드로 다시 라우팅하지만, 복제본이 상태를 공유하지 않고 재시작으로 선택된 엔드포인트가 변경되면 사용자의 세션이 손실될 수 있습니다.

고정 세션은 잘못된 로컬 세션 저장소 문제를 숨길 수 있습니다. 여러 앱 복제본이 프록시 또는 백엔드 교체 후에도 계속 작동해야 한다면 공유되는 내구성 있는 세션 상태를 우선 사용하세요.

안정적인 구성으로 테스트 계정 하나를 사용해 재현

구성을 스냅샷으로 저장하고, 삭제해도 되는 계정 하나로 로그인한 뒤 세션 식별자를 기록하세요. 그런 다음 프록시만 재시작하고 다른 구성 요소는 재시작하기 전에 동일한 요청을 테스트하세요.

ZimaSpace의 외부에서만 발생하는 로그인 루프 문서는 경로에 따른 로그인 실패를 다룹니다. 이 문서는 재시작 후 이미 유효한 세션이 동시에 무효화되는 문제에 초점을 맞춥니다.

프록시만 재시작해도 세션이 유지되고, 인증 또는 앱을 의도적으로 재시작해도 안정적인 비밀 키와 지속적인 상태가 사용되며, 모든 복제본이 동일한 활성 로그인을 허용하면 문제가 해결된 것입니다.

자주 묻는 질문

리버스 프록시 자체가 사용자 세션을 저장할 수 있나요?

인증 게이트웨이, 액세스 미들웨어 또는 고정 세션 기능이 포함되어 있다면 가능합니다. 단순한 전달 프록시는 일반적으로 애플리케이션 로그인 세션을 직접 관리하지 않습니다.

Redis를 재시작하면 항상 사용자가 로그아웃되나요?

세션이 Redis에만 존재하고 해당 데이터가 지속적으로 저장되거나 복원되지 않을 때만 그렇습니다. 데이터베이스 기반 세션이나 서명된 쿠키 세션을 사용하는 애플리케이션은 다르게 동작합니다.

재시작으로 인한 로그아웃을 막기 위해 쿠키 수명을 늘려야 하나요?

아니요. 쿠키 수명이 더 길어도 서명 키가 변경되거나 서버 측 세션 기록이 사라지면 쿠키는 작동하지 않습니다. 먼저 지속성과 비밀 키의 안정성을 해결하세요.