자격 증명 입력 후 Zimbra 웹메일 화면이 비어 있는 문제 해결

Zimbra 웹메일에서 사용자 이름과 비밀번호를 입력했는데 빈 페이지, 로딩 화면 또는 빈 사서함 창이 표시되는 경우, 원인을 확인할 때까지 로그인 후 로딩 오류로 간주하십시오. 자격 증명은 수락되었지만 웹 클라이언트가 인터페이스를 로드하거나 사서함 데이터를 가져오는 데 실패했을 수 있습니다. 빈 화면만으로는 원인을 파악할 수 없으며 사서함이 손상되었다는 것을 증명할 수도 없습니다.

유용한 결과는 반복 가능한 진단입니다. 즉, 오류가 특정 브라우저, 사용자, 사서함 서버 또는 모든 사용자에게 영향을 미치는지 판단하고, 최초 실패 요청 또는 서버 로그 항목을 식별한 다음, 증거와 일치하는 최소한의 변경 사항을 적용하는 것입니다. 아래 단계는 브라우저 검사와 관리자 작업을 분리하여 서버 구성을 변경하기 전에 액세스가 실제로 복구되었는지 판단할 수 있도록 합니다.

먼저, "로그인 후 빈 화면"이 무엇을 의미하는지 확인하십시오.

'로그인'을 선택한 직후에 발생하는 상황을 기록하세요. 주소창이 사서함 URL로 변경되나요? 페이지가 흰색으로 유지되나요, 로딩 표시가 계속되나요, 네트워크 서비스 오류가 표시되나요, 아니면 메시지 목록이 없는 메뉴가 나타나나요? 다른 사용자가 동시에 로그인할 수 있나요? 동일한 사용자가 개인 정보 보호 모드 브라우저 창이나 다른 기기에서 로그인하려고 해도 실패하나요?

이러한 세부 정보는 문제 해결 범위를 좁혀줍니다. 특정 브라우저에서만 문제가 발생하는 경우, 로컬 브라우저 상태 또는 확장 프로그램 문제일 가능성이 높습니다. 다른 계정은 정상적으로 작동하지만 특정 계정에서 모든 브라우저에서 문제가 발생하는 경우, 해당 사용자의 사서함, 환경 설정, 공유 폴더 및 사서함 로그를 확인하십시오. 여러 사용자의 계정에서 동시에 문제가 발생하는 경우, 웹 클라이언트 서비스, 프록시, mailboxd 및 최근 서버 변경 사항을 조사하십시오. 이러한 정보는 진단 단서일 뿐, 그 자체로 문제의 증거는 아닙니다. 조치: 문제 발생 시간, 영향을 받는 계정, 브라우저, 정확한 화면, URL 변경 여부를 기록하십시오. 암호나 세션 쿠키는 포함하지 마십시오.

사용자가 안전하게 시도해 볼 수 있는 것은 무엇일까요?

1. 개인 정보 보호 모드 창 또는 다른 지원되는 브라우저를 사용하여 테스트해 보세요.

Zimbra URL을 개인 정보 보호 모드 또는 시크릿 모드 창에서 열고 한 번 로그인해 보세요. 로그인이 정상적으로 된다면, 페이지, 스크립트, 쿠키 또는 개인 정보 보호 동작을 수정하는 브라우저 확장 프로그램을 일시적으로 비활성화한 후 일반 프로필로 다시 테스트해 보세요. 비교를 위해 다른 현재 사용 중인 브라우저에서도 시도해 보세요. 이렇게 하면 특정 프로필에 대한 문제를 파악할 수 있지만, 모든 브라우저에 영향을 미치는 서버 측 문제를 해결하는 방법은 아닙니다.

조치: 개인 정보 보호 모드와 일반 브라우저에서 동일한 계정과 네트워크를 비교하십시오. 두 모드 모두 동일한 지점에서 오류가 발생하면 브라우저 전환을 중단하고 타임스탬프와 결과를 관리자에게 보내십시오.

2. 개인 정보 보호 모드 테스트가 정상적으로 작동하는 경우, Zimbra 사이트 데이터만 삭제하십시오.

오래된 쿠키나 캐시된 웹 클라이언트 자산으로 인해 서버 업데이트 또는 로그인 변경 후 브라우저 세션이 불안정해질 수 있습니다. 개인 정보 보호 모드가 정상적으로 작동하는 경우, Zimbra 호스트 이름에 대한 쿠키와 캐시된 사이트 데이터만 삭제한 다음 사이트를 다시 열고 로그인하세요. 이렇게 하면 로그아웃되고 로컬 사이트 환경 설정이 삭제될 수 있으므로, 관리자의 요청이 없는 한 모든 브라우저 데이터를 삭제하지 마세요.

조치: 데이터를 삭제하기 전에 웹메일 주소를 정확히 알고 있는지, 필요한 다단계 인증 절차를 완료할 수 있는지 확인하십시오. 캐시를 삭제하지 않은 상태에서 빈 페이지가 표시되면 정확한 시간과 브라우저 버전을 기록해 두십시오. 캐시를 반복적으로 삭제해도 문제가 해결되지 않을 가능성이 높습니다.

3. 오류가 특정 계정에서만 발생하는지 확인하십시오.

다른 사용자는 Zimbra에 접속할 수 있지만 특정 계정만 접속할 수 없는 경우, 해당 문제를 관리자에게 보고하십시오. Zimbra의 로그인 후 화면 멈춤 문제 해결 페이지에서는 사서함 로그 확인 및 이전 사례의 경우 받은 편지함 검색이 문제의 원인인지 확인하는 방법을 안내합니다. 해당 페이지는 개발 중이며 예시도 오래된 내용이므로 사서함 환경설정을 변경하거나 메일을 이동하는 것이 모든 문제를 해결하는 만능 해결책은 아닙니다.

조치: 관리자에게 계정별 오류를 검사하도록 요청한 후 환경 설정, 공유 또는 메시지를 변경하십시오. 이메일을 삭제하거나 공유 폴더를 제거하는 것을 첫 번째 조치로 삼지 마십시오. 이전 절차는 로그 및 제어된 테스트를 통해 사서함 로딩 문제가 확인되고 관리자가 원래 설정을 복원하는 방법을 기록해 둔 경우에만 고려할 수 있습니다.

짐브라 관리자는 무엇을 먼저 확인해야 할까요?

먼저 이벤트 발생 시간과 영향을 받은 범위를 확인한 다음, 로그인 내역과 Zimbra 로그를 연관시켜 보세요. Zimbra 공식 문제 해결 페이지에서는 로그인이 멈춘 경우 먼저 mailbox.log다음 로그를 확인하고, 그 외 관련 로그를 확인하도록 권장합니다. Zimbra 로그 참조 목록에는 /opt/zimbra/log/mailbox.log, audit.log, nginx.access.log, nginx.log, 및 zmmailboxd.out가 나와 있으며, 로그 위치는 배포 환경에 따라 다를 수 있다는 점에 유의해야 합니다.

문제가 발생한 요청을 처리하는 서버에서 관리자는 문제를 재현하는 동안 관련 로그를 확인할 수 있습니다.

su - zimbra
tail -f /opt/zimbra/log/mailbox.log /opt/zimbra/log/nginx.access.log /opt/zimbra/log/nginx.log

배포 환경에 존재하는 경로만 사용하십시오. 다중 서버 설치 환경에서는 프록시 및 사서함 로그가 서로 다른 호스트에 있을 수 있습니다. 재현이 완료되면 Ctrl+C를 눌러 실시간 로그 기록을 중지하십시오. 조치: 특정 타임스탬프를 클라이언트 요청과 연관시켜 인증 성공 후 사서함, 프록시 또는 웹 클라이언트 요청 실패가 발생하는 부분을 찾으십시오. 개인 정보가 포함된 전체 로그 대신 개인 정보가 삭제된 짧은 발췌본을 공유하십시오.

출처: Zimbra의 로그인 후 문제 해결 문서 및 Zimbra의 로그 파일 참조 .

프록시 및 사서함 오류는 진단에 어떤 영향을 미칩니까?

사용자가 Zimbra 프록시를 통해 Zimbra에 접속하는 경우, 프록시 로그와 사서함 서버 로그를 모두 확인하십시오. Zimbra의 프록시 문제 해결 참조 문서에서는 nginx.log이를 nginx.access.log프록시 로그로 정의하고 있습니다. 502 및 503 응답은 업스트림 또는 서비스 오류로 설명하며, 503 오류는 일반적으로 Jetty mailboxd 프로세스를 사용할 수 없을 때 발생한다고 안내합니다. 5xx 응답은 빈 페이지만 표시되는 것보다 문제 해결에 더 중요한 단서가 되지만, 정확한 요청과 호스트를 파악하는 것도 중요합니다.

조치: 액세스 로그에서 첫 번째 실패한 요청과 해당 응답 코드를 찾은 다음, 프록시 오류 및 사서함 로그와 동시에 대조합니다. 로그에서 라우팅 또는 상위 시스템 오류가 지적될 경우에만 이름 확인, 네트워크 연결 가능성 및 특정 사서함 호스트의 상태를 점검하십시오. 한 사용자가 빈 페이지가 표시된다고 보고했다는 이유만으로 모든 Zimbra 서비스를 재시작하지 마십시오.

관리자는 Zimbra 제어 유틸리티를 사용하여 서비스 상태를 확인할 수 있습니다.

su - zimbra
zmcontrol status

"실행 중" 상태라고 해서 모든 웹 클라이언트 요청이 성공하는 것은 아닙니다. 요청 상태 및 사서함 로그와 함께 하나의 참고 자료로만 활용하십시오. 자세한 내용은 Zimbra 프록시 문제 해결 참조를 확인하세요 .

이 문제는 언제 특정 버전에서만 발생하는 웹 클라이언트 문제인가요?

Zimbra 위키에는 특정 이전 ZCS 릴리스로 업그레이드 후 발생하는 빈 페이지 오류 사례가 기록되어 있습니다. 한 문서에서는 서비스 등록 관련 해결 방법이 ZCS 8.6 및 8.7.0/8.7.1에 적용되며 웹 클라이언트에서 404 응답이 발생하는 문제를 보여준다고 설명합니다. 또 다른 문서에서는 mailboxd 시작 오류 및 503 응답이 발생하는 8.8.15 및 9.0.0 패치 시나리오를 별도로 기술하고 있습니다. 이러한 사례들은 특정 버전에 국한된 것으로, 현재 Zimbra 시스템에 대한 일반적인 지침은 아닙니다.

증상이 비슷하다는 이유만으로 해당 명령어를 복사하거나 서버 파일을 삭제하지 마십시오. 먼저 관련 문서에 설명된 정확한 Zimbra 버전, 패치 레벨, 업그레이드 내역, HTTP 응답 및 오류 서명을 확인하십시오. 위키 항목은 기존 문제 해결 페이지이며 일부는 작업 진행 중으로 표시되어 있습니다. 조치: 오류 서명과 버전이 일치하는 경우, 변경하기 전에 Zimbra 관리자 또는 지원 담당자에게 설치된 빌드에 대해 해결 방법을 검증받으십시오. 명시된 범위에 대해서는 이전의 빈 페이지 관련 문서 와 별도의 mailboxd/Jetty 사례를 검토하십시오 .

서버 로그에서 명확한 결론을 내릴 수 없을 때만 브라우저 개발자 도구를 사용하십시오.

관리자 또는 지원 기술자는 문제를 재현하는 동안 브라우저의 네트워크 및 콘솔 패널을 검사할 수 있습니다. 실패한 JavaScript 또는 스타일시트 자산, 반복적인 리디렉션, 차단된 요청, 혼합 콘텐츠 경고, 실패한 API 또는 SOAP 호출 등을 확인하십시오. 로그인 성공 후 웹 클라이언트 자산에 대한 404 오류가 발생하는 경우와 사서함 서비스의 502/503 오류는 서로 다른 계층의 문제임을 나타냅니다. JavaScript 예외는 클라이언트 측 오류를 식별하는 데 도움이 될 수 있지만, 처음 나타나는 오류가 항상 근본 원인은 아닙니다.

조치: 실패한 요청 경로, 상태 코드, 타임스탬프 및 익명 처리된 콘솔 메시지를 기록하십시오. 필터링되지 않은 HAR 파일, 인증 헤더, 로그인 응답, 사서함 내용 또는 쿠키를 공유하지 마십시오. 이러한 정보는 활성 세션 자격 증명 및 개인 메시지를 노출할 수 있습니다. 모든 요청이 성공적으로 반환되었지만 페이지가 여전히 비어 있는 경우 다른 브라우저와 비교하고 클라이언트 측 사용자 지정 또는 특정 릴리스의 웹 클라이언트 결함을 확인하십시오.

수리가 완료되었는지 어떻게 확인하나요?

문제가 발생한 사용자 계정과 필요한 경우 다른 계정을 사용하여 결과를 테스트하십시오. 로그인 후 사서함 인터페이스가 제대로 표시되고 폴더가 로드되며 최근 메시지 몇 개가 나타나는지 확인합니다. 메시지 하나를 열고 다른 폴더로 이동한 다음 정상적으로 로그아웃합니다. 그런 다음 원래 오류가 발생했던 브라우저에서 동일한 작업을 반복합니다. 여러 서버에 배포된 경우 사서함 호스트에서만 테스트하는 것이 아니라 공용 웹메일 URL을 통해서도 테스트하십시오.

로그인 폼이 사라졌다고 해서 문제가 해결된 것은 아닙니다. 페이지는 초기 로드 후에도 정상적으로 작동해야 하며, 로그에도 동일한 실패 요청이 더 이상 표시되지 않아야 합니다. 화면이 여전히 비어 있는 경우, 다음 사항들을 다시 확인하십시오. 특정 사용자 또는 여러 사용자, 특정 브라우저 또는 모든 브라우저, 특정 사서함 호스트 또는 모든 호스트, 그리고 어떤 요청이 먼저 실패했는지 등을 파악해야 합니다. 이를 통해 브라우저 문제 해결에서 사서함, 프록시 또는 버전별 문제 해결로 넘어가야 할 시점을 알 수 있습니다.