VPN 已连接但 IMAP 不同步？检查这三个层次

连接公司 VPN，打开邮件客户端，会发现网页邮箱能正常加载，而收件箱却拒绝刷新。常见的判断是 VPN 放行了流量却拦截了邮件，或者账户密码被改了。这两种猜测都跳过了 IMAP 客户端实际做了什么这一结构。到达主机、完成 TLS、通过认证和选择邮箱是四个不同事件，而 VPN 只负责第一个。

迷思：一条连接等于一次登录

人们以为，只要隧道建立、邮件服务器有响应，邮箱就已经实质打开。并非如此。VPN 只提供服务器的路径；它不替你登录，也不选择文件夹。客户端完全可能在隧道正常、密码有效的情况下卡在第四步。

「VPN 下 IMAP 坏了」的多数报告，实际上就出在这个缺口里。

IMAP 定义了未认证状态、已认证状态和已选择状态，命令只有在其允许的状态下才有效。当服务器提供预认证时，连接也可能一开始就是已认证的，因此没有弹出密码提示并不能说明任何问题。选择邮箱会把会话从已认证转入已选择，只有到那时，针对邮件的命令才有作用对象。

认证成功却选不中已配置文件夹的客户端，会表现为同步失败，而服务器其实运行正常。文件夹改名、服务商对「收件箱」的映射不同，或缺少访问权限，都会落在这里。服务器带标签的 NO 回应才是证据，它与密码被拒的回应不是一回事。

在 993 端口使用隐式 TLS 时，TLS 握手会在发出任何 IMAP 命令之前完成，因此证书问题会给出涉及信任而非邮件的报错。邮件主机名必须与证书匹配，和网站主机名一样；保留流量的隧道并不会让无效证书变得有效。

错误文本把情况区分开来。连接超时表示 SYN 从未完成。TLS 错误表示 TCP 连接成功而握手失败。IMAP NO 或 BAD 回应表示前两步都成功，是协议层拒绝了什么。改动任何设置之前，先记下你看到的是哪一种。

邮件客户端会显示此前下载过的邮件，无论今天能否连上服务器，所以看得见的收件箱只能说明本地存储正常。任何真实测试都必须强制一次服务器操作：刷新某个文件夹、拉取一封从未下载过的邮件，或发送一条只有选中邮箱后客户端才会发出的命令。

用非破坏性的检查。刷新一个文件夹、读取账户错误日志，胜过删除并重新添加账户，后者多半只能证明配置界面还能用。

发信是提交，不是 IMAP。它使用独立服务，通常也是独立端口，有自己的 TLS 模式和自己的认证，所以发件箱能用并不能证明选中了 IMAP 邮箱，发件箱坏了也不能归咎于 IMAP。

网页邮箱又是另一回事。它能在同一 VPN 上成功，因为它是对 Web 前端的 HTTPS 会话，这与桌面客户端的 IMAP 主机、端口或 TLS 模式无关。

交接时，把四项结果分开记录：VPN 路径、邮件端点与 TLS 结果、账户认证结果、邮箱选择结果。凭证与邮件内容不要写进记录。这份记录能让下一个人判断修复属于网络、证书、账户还是文件夹配置，同时不削弱任何一层保护。