Google engineer Gary Illyes has explained why Chrome 143 is causing cPanel access on port 2083 to fail for many users, along with a temporary workaround. According to Illyes, the issue stems from newer encryption defaults in Chrome colliding with firewall rules that are not prepared for them.
After updating to Chrome 143, users began reporting a familiar but confusing problem. cPanel links on port 2083 stopped loading, even though nothing appeared wrong with their hosting setup. DNS checks passed, servers were reachable, and other browsers worked as expected.
Illyes stepped in to clarify that the problem was not related to hosting outages or network instability. Instead, it came down to how Chrome now initiates encrypted connections and how some hosting firewalls respond to those requests.
What Users Are Seeing
The symptoms are consistent across many reports:
- cPanel pages hang indefinitely in Chrome
- The same URLs open normally in Firefox or Edge
- Access works when routed through port 443
- Only Chrome fails when connecting directly to port 2083
On the surface, this behavior looks like a server-side issue. Illyes explained that it is not.
What Changed in Chrome 143
According to Illyes, recent versions of Chrome automatically enable newer encryption features, including Post-Quantum Cryptography and Encrypted ClientHello. These changes affect how Chrome performs the TLS handshake when connecting to a server.
In practical terms, Chrome now advertises key exchange methods such as Kyber or ML-KEM alongside modern elliptic curve encryption. This makes the initial handshake packet significantly larger than before.
That increase in size is where the trouble begins.
Why Port 2083 Is Where Things Fall Apart
On standard web ports like 443, this larger handshake usually passes without issue. Port 2083, which is widely used for hosting control panels, often sits behind much stricter firewall rules.
Firewalls such as CSF or LFD may treat an unusually large packet arriving on a non-standard port as suspicious.
Instead of returning an error message or rejecting the connection cleanly, they often drop the packet silently. From Chrome’s perspective, the server simply stops responding halfway through the handshake.
This creates a situation where both sides are waiting. Chrome waits for a reply that never comes, while the server believes it has successfully blocked something potentially unsafe.
Why Firefox and Edge Still Work
The reason this problem feels inconsistent is that it is browser-specific. Firefox and Edge do not trigger the same failure in this setup, either because they do not enforce the same encryption options by default or because they negotiate a smaller initial handshake.
That difference alone is enough to explain why switching browsers immediately restores access, even though nothing has changed on the server itself.
The Only Temporary Fix Users Have
There is no longer a simple setting inside Chrome to disable these newer encryption features. The relevant flags have been removed.
The workaround described in the original report involves enforcing Chrome policies at the system level.
On Windows, this means disabling Encrypted ClientHello and Post-Quantum Key Agreement through the registry.
After restarting Chrome, the browser falls back to standard key exchange methods, which reduces the handshake size enough for the firewall to accept the connection.
The change can be verified using Cloudflare’s trace tool:
- If the key exchange shows X25519MLKEM768, Chrome remains locked out
- If it shows X25519, cPanel access on port 2083 usually works again
Why This Is Not a Long-Term Answer
Disabling modern encryption features is not a solution anyone should feel comfortable with long-term.
While the risk of future quantum attacks may seem distant, deliberately weakening browser security is a compromise, not a fix.
The real responsibility sits with hosting providers. Firewalls need to be updated to handle larger TLS handshake packets on ports used for administrative access. Until that happens, users are left choosing between up-to-date browser security and basic access to their servers.
What Users and Admins Should Do Now
If cPanel access suddenly breaks after a Chrome update, testing the same URL in another browser is a quick way to confirm whether this issue is the cause. Using port 443, if available, may also bypass the problem.
Any registry-based workaround should be treated as temporary. Reporting the issue to the hosting provider is essential because only firewall updates can address the root cause.
Why This Matters Beyond One Browser Update
This situation highlights a growing gap between modern browser security practices and older server defenses.
As browsers continue to strengthen their defaults, infrastructure that does not adapt will increasingly fail in subtle and confusing ways.
Security that prevents people from accessing their own systems does not feel protective. It feels broken.
Key Takeaways
- Gary Illyes identified Chrome’s newer encryption defaults as the cause of cPanel failures on port 2083.
- The issue occurs when hosting firewalls silently drop larger TLS handshake packets.
- Other browsers continue to work because they negotiate smaller or different handshakes.
- The workaround suggested by Illyes restores access but lowers security standards.
- A permanent fix requires hosting providers to update firewall rules.
Zulekha
AuthorZulekha is an emerging leader in the content marketing industry from India. She began her career in 2019 as a freelancer and, with over five years of experience, has made a significant impact in content writing. Recognized for her innovative approaches, deep knowledge of SEO, and exceptional storytelling skills, she continues to set new standards in the field. Her keen interest in news and current events, which started during an internship with The New Indian Express, further enriches her content. As an author and continuous learner, she has transformed numerous websites and digital marketing companies with customized content writing and marketing strategies.