网页版和客户端不是一回事：先区分协议、端口，别急着怀疑网络
网页版邮箱靠浏览器和邮件服务器之间的一次HTTPS会话完成收发展示，走的是443端口，只要账号密码对、网站能打开，几乎不会因为端口被挡而失败。邮件客户端是另一套体系：收信通常走IMAP或POP3，发信走SMTP，各自占用独立的端口，收信常见993，发信常见465或587，跟网页版的443完全不是一回事。
很多公司网关、公共Wi-Fi甚至部分家庭路由器只放行常见的网页端口，对邮件专用端口做了拦截或限速，结果就是网页版一切正常，客户端却报连接失败、认证失败或者干脆卡在正在连接。这不是网络整体坏了，而是某几个特定端口被挡住了，网页版走的那条路根本没受影响，所以看起来才这么矛盾。
Android上一边正常一边失败，多半是加速的应用列表问题
如果是在Android手机上遇到网页正常、客户端失败的情况，还要多看一层：手机上的加速通常是按App单独设置的，浏览器和邮箱App可以走完全不同的网络路径。如果邮箱App没有被加入需要加速的应用列表，而浏览器加入了，两者本来就走的是两条不同的路径，一个正常一个失败并不奇怪——先去应用列表里确认邮箱App的状态，比反复重新连接更有效。
列表能刷新、附件传一半就卡住：这是两类完全不同的故障
邮件列表刷新只是拉取一批很小的元数据，请求体量小、耗时短，网络稍有波动也基本能扛过去。附件收发是一段持续时间更长的传输，尤其是几MB甚至更大的附件，需要链路在整个传输窗口里保持稳定，中间哪怕只出现短暂的丢包、抖动或者连接被重置，都足以打断这段长传输，但短小的元数据请求可能完全不受影响。
所以列表能刷新不代表链路完全健康，它只证明短请求没问题，并不能替代对长传输的检验。两种失败的表现也不一样：端口被挡通常是立刻报错或者根本连不上，而长传输被打断往往是进度条卡在中途、转一会儿才提示超时，发生的时间点和提示语都不同，值得留意。
「已发送」不等于「对方已收到」：多半是投递策略在起作用
客户端界面显示邮件已发送，只代表本地客户端已经把这封信成功交给了你这边设置的发件服务器，完成了本地到发件服务器的第一跳，仅此而已。至于对方的邮件服务器要不要接收、放进收件箱还是判定为可疑邮件直接过滤掉，是由收件方自己的投递策略决定的，这套判断会综合发件域名的信誉记录、SPF和DKIM等身份校验结果、邮件内容和附件类型，甚至临时的灰名单延迟机制，统统发生在对方服务器那一侧，跟你和对方之间这段网络链路是否通畅完全无关。
哪怕发送过程全程零丢包、速度飞快，只要投递策略判定这封信不可信，照样会被悄悄拦下，而且大多数情况下发件人根本收不到任何提示，看起来就像信凭空消失了。这也是为什么反复检查网络、反复重发往往没有用——问题根本不在传输这一段。这里也要说清楚一件容易被误解的事：像远航极速这样的加速工具，出口节点只在美国、日本和香港，且为多个用户共用，出口IP过去被别的账号用出的信誉记录不是加速工具能控制或改写的一层，用它做跨境办公能让连接更稳定地送达对方服务器，但不应该被当作能够改变对方那一层投递判定的手段，这两件事要分开看。
快速分辨，再走完整的处理顺序
先做一个10秒测试：发一封不带附件的纯文字邮件给自己另一个不同域名的邮箱账号。如果几秒内就能收到，说明发送链路和投递本身都没问题，之前「对方没收到」更可能是对方那一侧的策略判断；如果这封测试信也收不到，问题大概率出在链路或协议端口这一层，而不是投递策略。
- 先用浏览器登录同一个邮箱账号，确认账号密码和邮箱服务本身没有问题，这一步正常才有必要往下查。
- 打开邮件客户端的账户设置，核对收信、发信服务器的地址和端口号，确认填的是IMAP/POP3和SMTP专用端口而不是网页端口。
- 发一封不带附件的纯文字邮件，测试最基础的收发链路是否通畅。
- 再发一封带小附件的邮件，观察进度条是卡在传输中途还是根本发不出去，区分长传输被打断和端口连接本身不通。
- 如果怀疑是对方没收到，用自己另一个不同域名的邮箱账号做交叉测试，把投递策略问题和网络链路问题分开验证。
- 确认问题确实出在本机网络环境导致邮件端口被限制之后，才考虑更换网络路径，比如在Windows上使用系统级隧道接管全部端口的流量，但要清楚这只解决链路通不通，解决不了对方那一层的投递策略判定。
邮件客户端用的是和网页版完全不同的协议与端口，浏览器层面的代理两者都覆盖不到。系统层的隧道会把客户端收发用的那些端口一起带上，不必单独为邮件程序配置。
安卓与 Windows 客户端已上线，macOS 与 Linux 开发中。iPhone 暂无原生客户端。出口服务器的访问日志是关闭状态；会话记录表里没有目标地址、域名或 URL 字段。注册即可使用永久免费套餐，按月发放流量额度。客户端在连上之后会做一次真实探测，探测不通就不显示已连接。
据 IETF RFC 8314 所建议，邮件客户端应当使用隐式 TLS 的端口收发信件，收信用 993、发信用 465，这跟网页访问所用的端口是两套。
常见问题
网页版邮箱能打开，客户端却提示连接失败，是VPN的问题吗？
网页版走的是443端口的HTTPS会话，邮件客户端走的是IMAP、POP3、SMTP这些完全不同的端口协议，443能通不代表邮件专用端口也能通，这多半是端口被挡而不是VPN本身的问题。
邮件列表能刷新，但附件传一半就卡住，说明什么？
列表刷新只是拉取轻量的元数据，附件收发是一段更长的持续传输，轻微的丢包或链路波动足以打断长传输却不影响短请求，所以两者会表现出完全不同的故障方式。
客户端显示邮件已发送，但对方说没收到，是不是网络断了？
客户端的已发送只代表邮件已经交给了你这边的发件服务器，之后对方服务器是否接收、放入收件箱还是判定为垃圾邮件，是收件方的投递策略决定的，跟发送时的网络状况没有关系。
在Android手机上，邮箱App收不到信但浏览器网页版正常，怎么排查？
Android上的加速通常是按App分别设置的，如果邮箱App没有被加入加速的应用列表而浏览器加入了，两者走的网络路径本身就不同，这种一边正常一边失败的表现是配置差异造成的，不是信号问题。
用远航极速的Windows客户端连上之后，邮件客户端还是收不到信，是隧道没生效吗？
Windows上的隧道是系统级的，理论上会接管包括邮件客户端在内的全部流量端口，如果这时候仍然只有邮件客户端收不到而其他都正常，更应该先核对客户端里填写的服务器端口是否正确，而不是怀疑隧道本身。
换了网络路径之后，对方还是收不到我发的邮件，继续换网络有用吗？
如果问题出在收件方服务器的投递策略判定上，换多少次网络路径都不会改变对方那一层的判断，先用自己另一个邮箱账号做交叉测试，才能确认问题到底出在链路上还是投递策略上。
免费版流量额度用完之后，邮件收发会不会突然全部失败？
免费版的月度流量额度用完后，当月的加速会停止，下个月恢复，如果频繁收发大附件导致额度提前用尽，表现出来的是速度变化而不是协议或端口错误，这跟前面说的收发故障是两类不同的原因。
零日志设计跟邮箱收发问题有关系吗？
零日志设计说的是连接的目的地不会被记录下来，这跟邮件本身能不能收发是两件事，遇到收发异常还是要按协议端口和投递策略这两条线去排查，不能指望它改变邮件的送达结果。