Fixing ProtonMail Bridge Connection Issues

The migration job points at 127.0.0.1:1143, the credentials match what Bridge displays, and it still fails with ECONNREFUSED or AUTHENTICATIONFAILED. ProtonMail Bridge is the bottleneck on every Proton migration, and the failures usually trace back to one of four issues: Bridge isn't running, the wrong password was used, a firewall blocks loopback, or a stale account session inside Bridge needs to be refreshed. This post walks through each in the order you should check them.

Why Bridge is the only IMAP path for Proton#

Proton encrypts mail at rest with PGP keys that only you hold. Their servers cannot hand a third-party IMAP client decrypted messages — they don't have the key to decrypt them with. Bridge solves that by running locally on your machine, holding the decryption key in memory while you're signed in, and exposing a normal IMAP/SMTP interface on the loopback address. The migration tool talks to Bridge, Bridge talks to Proton.

That architecture has a few hard consequences:

• Bridge must be running and signed in for the duration of the migration
• The migration host must be the same machine as Bridge — 127.0.0.1 is not routable
• Each IMAP client gets its own randomly-generated Bridge password; you never pass your Proton account password to the migration tool
• Free Proton accounts don't get Bridge; only paid plans

If any of those four constraints is unmet, the migration will fail at the connection or auth stage.

Reading the error messages#

The four common errors and what they mean:

• ECONNREFUSED 127.0.0.1:1143 — Bridge is not running, or it crashed
• AUTHENTICATIONFAILED — wrong password (almost always: someone pasted the Proton account password instead of the Bridge-generated one)
• Connection timeout — host firewall or endpoint protection is blocking loopback
• NO Account is not signed in — Bridge is running but the specific account has been signed out, often after a long idle period or a Proton password change

The fix flow#

1. Confirm Bridge is running and signed in

   Open the Bridge app on the migration machine. The account should show a green status. If it shows signed out, sign in with your Proton credentials (and second factor if you have 2FA on). Bridge can sit signed out after sleep, after a system update, or after a Proton password change.

2. Reveal and copy the Bridge IMAP password

   Inside Bridge, expand the account and click the eye icon next to the IMAP password to reveal it. Copy it exactly — Bridge uses a non-ambiguous alphabet, but a stray space at the end of the paste will still fail. The displayed password is regenerated if you click "reset"; don't reset unless you intend to update every client at once.

3. Configure the source in Mailbox Taxi

   Add a new source connection. Pick ProtonMail (via Bridge) if available, otherwise Custom IMAP with: host 127.0.0.1, port 1143, security STARTTLS, username your full Proton email address, password the Bridge-generated string. Do not use SSL on port 1143 — Bridge uses STARTTLS by design.

4. Allow loopback in firewall and antivirus

   On Windows, check that Windows Defender Firewall does not have an outbound rule blocking the migration binary from connecting to localhost. On macOS, the application firewall does not block loopback by default but some endpoint protection products do. On Linux, check that iptables -L OUTPUT does not have a rule blocking lo traffic. If you're not sure, temporarily disable third-party endpoint protection for a 30-second test connection.

5. Test with a small folder

   Before queueing the full mailbox, migrate a single small folder — usually Sent. This proves the full chain works end-to-end: Bridge decrypted the messages, IMAP delivered them on 1143, the migration tool read them, and the destination accepted them. Once that works, queue the rest.

Edge cases worth knowing#

Bridge consumes serious memory on large mailboxes#

A 30 GB Proton mailbox can push Bridge's memory use over 2 GB while in use. If your migration host has 8 GB of RAM and you're also running other workloads, Bridge can be killed by the OS memory manager and the IMAP server vanishes mid-run. Close other applications, or move the migration to a host with at least 16 GB of RAM for any mailbox over 20 GB.

Two-factor reset breaks the Bridge session#

If you reset 2FA on your Proton account during the migration, Bridge's saved session is invalidated and you have to sign in again. The migration tool will see NO Account is not signed in until you do. Sign in, then resume the job — Mailbox Taxi picks up from the last committed UID.

Bridge on a headless Linux server#

Bridge has a CLI mode that doesn't need a desktop session. Sign in once interactively, then run it as a systemd service. The IMAP endpoint still binds to 127.0.0.1:1143 only, so the migration must run on the same host. This is the right pattern for unattended large migrations.

Calendar and contacts are out of scope#

Bridge is mail-only. Proton Calendar and Proton Contacts have to be exported through the Proton web app and imported separately into the destination. None of the Proton migration guides — Proton to Gmail, Proton to Office 365, Proton to Outlook — cover calendar via Bridge because Bridge doesn't expose it.

When the connection still fails#

If you've completed all five steps and the migration still won't connect, two more checks remain:

• Run telnet 127.0.0.1 1143 from a terminal on the migration host. If telnet can't connect either, the issue is loopback, not the migration tool.
• Restart Bridge entirely (quit, relaunch, sign in). About 5% of connection issues are stale internal state inside Bridge that a restart resolves.

For background on what STARTTLS, IMAP LOGIN, and LIST actually do — useful when you're reading Bridge's verbose logs — the IMAP protocol glossary covers the commands. For the broader catalog of provider-specific migration errors by symptom, the troubleshooting hub is the index page.