Full check record from Thunderbird connection failure to switching to Gmail API client

1. The first problem of the problem

When using Thunderbird on Ubuntu 26.04 recently, an error pops up in a pop-up window:

Thunderbird cannot connect to imap.gmail.com, please try again later. If the problem persists, it may be that you exceed the maximum number of connections allowed by this server. The number of cached connections can be reduced in the IMAP server settings.

Although the maximum number of connections is adjusted to 1, even all Google-related cookies and saved passwords are cleared, and the OAuth 2.0 authentication is re-authenticated, the problem still exists. What’s even more strange is that all other mailboxes on Thunderbird (such as 163.com) are normal, but NetEase Mail Master on Android phones can receive Gmail emails normally.

2. Preliminary investigation: client and agent

1. Connection settings: has been set to 1 to exclude client concurrency restrictions.
2. Proxy configuration: Invalid TUN mode (virtual network card) or manual proxy using Clash Verge Rev. Even if the proxy is closed (Google cannot be accessed in the country), or the system proxy is used instead, Thunderbird still cannot connect.
3. Clear authentication information: Repeatedly delete cookies and passwords, reauthorize OAuth2, the authentication window can pop up, but the subsequent IMAP synchronization still fails.

3. In-depth server-side diagnosis

Since there is no problem with the client configuration, we log in to the VPN server (located in Los Angeles, self-built WireGuard + Wstunnel) for network testing.

1. Test basic connectivity

curl -v https://www.google.com

Returns 200 successfully, indicating that HTTPS (443) is reachable.

2. Test the mail port

nc -zv smtp.gmail.com 587   # 成功
nc -zv smtp.gmail.com 465   # 成功
nc -zv imap.gmail.com 993   # 卡住，无响应
nc -zv imap.gmail.com 143   # 卡住
nc -zv pop.gmail.com 995    # 卡住

Conclusion:The SMTP sending port is unblocked, but all the incoming ports (IMAP/POP3) cannot be connected.

3. DNS resolution is normal

dig imap.gmail.com
# 返回 142.250.141.108/109
dig smtp.gmail.com
# 返回 142.250.101.109

The domain name resolution is correct, the problem is not in DNS.

4. Try hosts bindings

Will imap.gmail.com Forcing IPs to SMTP (142.250.101.109), the result 993 port still times out, indicating that it is not an IP routing problem, butPort is shielded.

5. Routing Tracking

sudo traceroute -T -p 993 142.250.101.109

output:

1  _gateway (154.21.196.254)  3.748 ms ...
2  * * *
...
30 * * *

The data packet is lost immediately after leaving the server gateway, certifying that the service provider (zgovps.com) is exported to its networkClearly blocked TCP 993 ports(May also include 995, 143).

The root cause

• Service provider restrictions:ZGoVPS filters non-web service common ports (IMAPS, POP3S) in the outbound direction, and only reserves SMTP (465/587) for sending letters.
• Why can the mobile phone NetEase mailbox master receive letters? It does not directly use the IMAP protocol, but throughNetease server transferOr call Gmail API (based on HTTPS), avoiding port restrictions.

The solution

Since the service provider cannot release the port (the console has no relevant setting entry, and it may be fruitless after submitting the work order), we can only change the communication method between the client and Gmail.Switch to mail clients that support Gmail APIIt is the most direct way, because the Gmail API uses HTTPS (443), which is unblocked.

6. Summary and Reflection

1. Diagnostic Logic of Network Problems: From the client → proxy → server → port → routing, progress is the key to the positioning problem.
2. Transition value of third-party services: Applications such as NetEase Mail Master can ‘bypass’ the restrictions, thanks to its server cluster or API calls, which shows that we should make good use of the API instead of the traditional protocol under the restricted network.
3. Consider the network environment when selecting a tool: For domestic self-built VPN users, be sure to confirm whether the service provider is blocking the commonly used mail port, otherwise the HTTPS-based client should be preferred.

This experience has shifted me from relying on Thunderbird to the more modern Gmail API client. Although the habit needs to be changed, the efficiency and stability have been improved. I hope this record can help friends who encounter similar difficulties to avoid detours.