Immich 오류가 클라이언트에서 발생했는지 서버에서 발생했는지 확인하는 방법

Immich 오류가 클라이언트 측인지 서버 측인지 확인하려면 변수 하나만 변경한 채 동일한 작업을 재현하고, 실패한 요청이 경로를 따라 어디에서 중단되는지 추적하세요.

“서버 오류”라고 표시되는 모바일 배너도 실제 원인은 클라이언트 상태, TLS, 리버스 프록시 또는 서버가 올바르게 거부한 요청일 수 있습니다. 마찬가지로 브라우저에서만 발생하는 실패가 브라우저 자체의 문제라는 뜻은 아닙니다. 계정, 자산, 작업을 동일하게 유지하고 클라이언트와 경로를 비교한 다음, 상태 코드와 동기화된 로그를 사용해 처음 실패한 계층을 찾아보세요.

두 번째 클라이언트에서 동일한 작업 재현

로그인, 알려진 자산 열기, 동일한 작은 사진 업로드, 동일한 검색 실행처럼 결정적인 작업 하나를 선택하세요. 네트워크 경로는 그대로 유지하면서 브라우저와 모바일 클라이언트에서 동일한 계정으로 반복합니다. 두 시도의 정확한 시간과 결과를 기록하세요.

Android 클라이언트는 실패했지만 다른 접속 경로가 테스트된 최근 Immich 보고서는 클라이언트 간 비교의 가치를 보여줍니다. 한 스레드의 원인을 일반화할 수는 없지만, 클라이언트별 결과를 확인하면 다음에 조사할 범위를 크게 좁힐 수 있습니다.

모든 클라이언트에서 같은 시간에 동일한 작업이 실패한다면 서버, 데이터베이스, 스토리지 또는 공유 네트워크 경로의 가능성이 높아집니다. 동일한 엔드포인트를 통해 한 클라이언트만 실패하고 다른 클라이언트는 성공한다면 클라이언트 버전, 캐시된 상태, 권한, 로컬 인증서 신뢰 및 서로 다른 정확한 요청을 확인하세요.

계정이나 자산은 바꾸지 않고 경로 변경

다음으로 신뢰할 수 있는 로컬 경로와 일반적인 리버스 프록시, VPN, 터널 또는 원격 경로를 비교하세요. 동일한 계정과 작업을 사용합니다. 로컬에서는 성공하지만 원격에서는 실패한다면 미디어 레코드 자체보다는 DNS, TLS, 프록시, 방화벽 또는 업스트림 라우팅 계층에 문제가 있을 가능성이 높습니다.

ZimaSpace의 로컬 및 원격 경로 진단 가이드는 LAN 성공과 인터넷 성공이 서로 다른 증거인 이유를 설명합니다. 모바일 앱을 재설치하거나 서버를 재구축하기 전에 이 기준을 Immich에 적용하세요.

두 경로에서 동일하게 실패한다면 프록시 설정 변경을 중단하고 애플리케이션 측 요청을 검사하세요. 프록시 경로에서만 실패한다면 프록시 상태, TLS 결과, 업스트림 응답 및 타임아웃을 수집하세요. 이 단일 변수 비교를 활용하면 클라이언트 메시지 때문에 잘못된 계층을 조사하는 일을 막을 수 있습니다.

상태 코드는 최종 결론이 아닌 단서로 활용

HTTP 상태 코드는 조사할 위치를 분류하는 데 도움이 되지만, 문제를 일으킨 구성 요소를 자동으로 식별해 주지는 않습니다. 4xx는 대개 요청, 인증 또는 권한이 허용되지 않았다는 뜻이고, 5xx는 서버 측 구성 요소가 요청을 처리하지 못했다는 뜻입니다. Immich가 요청을 받기 전에도 프록시가 두 상태 코드 중 하나를 생성할 수 있습니다.

액세스 로그 필드 가이드는 상태 코드, URL 경로, 요청 시간, 원격 호스트 및 요청 식별자를 유용한 문제 해결 필드로 강조합니다. 관련 없는 수천 줄을 훑는 대신 실패한 작업 하나에 대한 이러한 값을 수집하세요.

프록시에는 502 또는 타임아웃이 기록되지만 일치하는 Immich 요청이 없다면 업스트림 경로를 추적하세요. Immich가 요청을 기록하고 결정적인 4xx를 반환한다면 인증, 권한 또는 요청 내용을 검사하세요. 클라이언트는 실패를 보고하지만 모든 서버 측 계층이 2xx를 표시한다면 클라이언트의 파싱, 로컬 캐시 또는 후속 요청을 검사하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

하나의 타임스탬프에서 오류율, 지연 시간 및 서버 로그 상호 연관

실패한 요청 하나는 예외적인 사례일 수 있습니다. 관련 서버 및 프록시 로그를 확인하면서 작업을 5~10회 재현하고 성공률과 지연 시간을 기록하세요. 리소스 압박이나 대기열 급증 중에 오류가 증가한다면 두 번째 시도는 성공하더라도 서버가 간헐적으로 이용 불가능한 상태일 수 있습니다.

Better Stack의 서비스 신호로서의 오류와 지연 시간 개요는 오류율을 지연 시간 및 트래픽과 구분합니다. 이 관점은 잘못 구성된 단일 클라이언트 요청과 부하가 걸릴 때만 저하되는 서버 경로를 구분하는 데 도움이 됩니다.

여러 클라이언트에서 서버 로그에 동일한 예외가 나타난다면 반증될 때까지 서버 측 문제로 간주하세요. 서버가 실패한 요청을 전혀 확인하지 못한다면 DNS, TLS, 프록시 및 클라이언트 네트워킹을 추적하세요. 한 클라이언트만 다른 형식의 요청을 생성한다면 차이를 확인할 수 있을 만큼 충분한 증거를 보존한 후 해당 클라이언트를 업데이트하거나 초기화하세요.

2×2 테스트로 최종 판단

두 클라이언트와 두 경로를 사용하세요. 브라우저-로컬, 브라우저-원격, 모바일-로컬 및 모바일-원격 조합을 테스트합니다. 동일한 계정과 테스트 자산을 유지하세요. 이 매트릭스를 사용하면 클라이언트별 실패, 경로별 실패, 모든 조합에 영향을 주는 서버 실패를 구분할 수 있습니다.

한 클라이언트는 두 경로에서 모두 실패하고 다른 클라이언트는 통과한다면 클라이언트 원인을 뒷받침합니다. 두 클라이언트가 한 경로에서만 실패한다면 경로 원인을 뒷받침합니다. 네 가지 조합 모두에서 동일한 애플리케이션 오류가 재현되고 서버 로그에 동일한 실패 작업이 표시된다면 서버 원인을 뒷받침합니다.

확인된 계층을 수정한 후 네 가지 조합을 모두 다시 실행하고 문제가 된 구성 요소를 한 번 재시작하세요. 원래 실패한 조합이 통과하면서 대조군에는 문제가 생기지 않을 때 중단합니다. 일반적인 스크린샷 대신 매트릭스, 타임스탬프, HTTP 상태 코드, 프록시 및 서버 로그 발췌, 클라이언트 버전, 재현 가능한 요청 하나를 포함해 문제를 에스컬레이션하세요.