Outlook 캐시된 메일은 열리지만 아무것도 동기화되지 않을 때: 무엇을 확인할까

오래된 메일은 열리고 폴더 목록도 정상으로 보이지만, 오늘 아침 보낸 메시지는 보낼 편지함을 떠나지 않습니다. 이 조합은 로컬 캐시는 정상이고 Exchange 연결은 정상이 아니라는 뜻이며, 이 분야 전체에서 가장 흔히 오해되는 증상입니다. 아무것도 충돌하지 않았기 때문에 보통 보고는 Outlook이 끊겼다기보다 Outlook이 느리다는 형태로 들어옵니다.

점검은 순서대로 진행하고, 무엇보다 먼저 어떤 Outlook 빌드를 보고 있는지 적어 두세요. 컨트롤이 다르기 때문입니다.

어떤 클라이언트와 어떤 계정 유형인지 확인

Windows용 클래식 Outlook, 새 Outlook, 웹의 Outlook은 서로 다른 연결 경로를 가진 세 가지 클라이언트이며, 한쪽에 맞는 조언이 다른 쪽에는 자주 틀립니다. 클래식 Outlook 안에서는 서버에 연결할 수 없을 때 Exchange 계정과 POP 또는 IMAP 계정이 다르게 동작합니다. MAPI 전송과 캐시된 사서함 저장소는 Exchange 계정에만 있기 때문입니다. 상태를 해석하기 전에 계정 설정에서 계정 유형을 확인하세요. IMAP 설정에서 복사한 해결책은 Exchange 연결을 설명하지 않습니다.

클라이언트 이름과 버전을 적어 두세요. 지원 스레드에서는 이 둘이 자주 뒤섞이고, 스크린샷은 중간부터 일치하지 않습니다.

실패하는 동안 연결 상태 읽기

클래식 Outlook이 실행 중인 상태에서 Ctrl을 누른 채 알림 영역 아이콘을 마우스 오른쪽 단추로 클릭하고 연결 상태를 여세요. 다시 시작한 뒤가 아니라 실패하는 작업 중에 해야 합니다. 이 보기는 그 순간 클라이언트가 무엇을 시도하는지 알려주기 때문입니다. 서버 이름, 프로토콜, 상태를 기록한 다음 그 서버를 계정이 사용할 것으로 예상하는 서버와 비교하세요. Microsoft의 진단 지침은 이 보기와 요약으로 충분하지 않을 때 수집할 수 있는 더 자세한 로깅을 다룹니다.

현대 Exchange 배포는 Outlook 트래픽을 MAPI over HTTP로 전달하므로 SMTP 제출 포트를 여는 것은 사서함 연결의 수리가 아닙니다. 전송이 서비스에 도달한다면 HTTP 또는 인증 오류를 보관하고, 문제가 된 적 없는 암호를 재설정하는 대신 그 단계에서 작업하세요.

엔드포인트를 브라우저 경로와 비교

웹 사서함이 작동한다는 것은 브라우저가 하나의 이름과 하나의 프록시 구성으로 하나의 엔드포인트에 도달할 수 있음을 증명합니다. Outlook이 같은 주소를 확인했고, 같은 경로를 사용했고, 같은 인증서를 수락했음을 증명하지는 않습니다. VPN이 있으면 분할 DNS가 Outlook 이름을 내부 주소로 보내는 동안 브라우저는 공용 주소를 사용할 수 있고, 그 차이만으로도 고장 난 클라이언트 옆에서 웹 세션이 작동하는 것을 설명할 수 있습니다. 확인된 주소, 선택된 경로, TLS ID를 두 경로에서 비교하세요.

관리 포털과 원격 PowerShell은 사용자 사서함 테스트를 대신하지 못합니다. 서로 다른 인증을 쓰는 다른 서비스이기 때문입니다.

새 작업으로 캐시 시험

캐시된 Exchange 모드는 로컬 복사본을 유지하고 서버와 동기화하므로 중단에 강하지만 서버로부터 독립적이지는 않습니다. 오래된 캐시 메시지를 읽는 것은 네트워크 테스트가 아니며, 오프라인 작업 토글도 마찬가지입니다. 새 메시지를 보내거나 동기화를 강제하고 그 특정 작업을 관찰하세요. 작은 교환이 성공하는데 큰 전송이 멈춘다면 패킷 크기와 경로 MTU에 주의할 가치가 있으며, 실패한 작업에서 증거를 수집하세요.

캐시 모드를 바꾸면 경로나 서비스를 고치지 않고 증상만 옮겨갈 수 있습니다.

지원되는 수정을 한 뒤에는 원래 작업을 반복하고 새 데이터가 서버에 도달해 돌아오는지 확인하세요. 그 결과는 이미 디스크에 있던 메일을 읽는 편리함과 별도로 기록하세요.