e1.techartery.com — Under the Surface

On 2 November 2026, e1.techartery.com began returning Cloudflare error 522 — Connection timed out. The site was unreachable. On the same server, www.sportkin.com was loading without complaint. The investigation began.

At first glance, the symptoms pointed in every direction at once. Cloudflare reported the host as unreachable, but Apache reported itself healthy. Local tests returned 200 OK. External tests returned 200 OK. And yet Cloudflare kept timing out after nineteen seconds with zero bytes returned. The early assumptions were reasonable, and wrong. The HTTPS virtual host was missing — added. The firewall was inspected — clean. Fail2ban was reviewed — no Cloudflare IPs banned. The server load was checked — idle. Each test eliminated a suspect. Each answer raised a new question.

The breakthrough came not from a new command, but from an overlooked observation. A browser pointed at the server on port 443 returned an Apache error: "You're speaking plain HTTP to an SSL-enabled server port." That error proved that port 443 was open and reaching Apache from the outside world. Which meant the problem wasn't 443 at all. It was 80.

Port 80, the plain-HTTP port, the port Cloudflare's Flexible mode uses to fetch pages from the origin, was blocked upstream at the router. Locally it responded instantly. Externally, it never arrived. Cloudflare was knocking on port 80, getting nothing, and returning 522. The server was never the problem.

Two Hosts, Two Different Paths

Sportkin continued to work throughout because it does not use Cloudflare at all. Its DNS is served by NS1, a DNS and traffic-management platform with a fundamentally different design philosophy: it answers the DNS question and then steps out of the way. The browser connects directly to the origin server. There is no proxy in the middle, no edge network re-fetching pages, and no dependency on a specific origin port that Cloudflare chooses to use.

That architectural difference mattered during this outage. Cloudflare's proxy model adds capabilities — caching, DDoS absorption, edge TLS, WAF rules — but it also inserts a dependency between the visitor and the origin. When that dependency's assumptions don't match the origin's reality (in this case, Cloudflare expecting to fetch on port 80 while port 80 was blocked upstream), the site goes down even though the origin itself is healthy.

NS1's answer-only model has fewer moving parts on the visitor path. There is no edge node deciding which port to fetch on, no cached 522 to clear, no mode setting to reconcile. The trade-off is that NS1 does not offer the same bundled caching and DDoS protection — those become separate concerns, typically handled at the origin or by a dedicated layer. But for a host like sportkin that already has a stable origin and doesn't need edge caching, the simplicity is an advantage: there is less to go wrong between the visitor and the server.

Neither model is universally better. Cloudflare's proxy is the right choice when edge caching and DDoS mitigation are priorities. NS1's authoritative-only approach is the right choice when the origin is already capable and the goal is fewer intermediaries. The e1 outage was a reminder that these are genuine architectural choices with different failure modes — not interchangeable labels on the same service.

What Was Fixed

A self-signed certificate was generated for e1.techartery.com and a dedicated HTTPS virtual host was added to Apache. This ensured that requests arriving on port 443 with the correct SNI would be served by the e1 vhost, not the default sportkin vhost. Apache reloaded cleanly. apachectl -S confirmed the vhost was registered. Local and external 443 tests both returned 200 OK.

Cloudflare's SSL/TLS mode was then switched from Flexible to Full, causing Cloudflare to fetch the origin on port 443 — the port proven open — instead of port 80. The cache was purged. The 522 cleared.

The Data Migration

With the site restored, attention turned to the underlying software. MantisBT 1.1.8 — a tracker written in 2009, built for PHP 5 — was running on a PHP 8.5 stack. The tracker's database, skizcorp_tracker, held 29 MyISAM tables in latin1_swedish_ci, schema version 63. Modern expectations — and the surrounding stack — assume InnoDB and utf8mb4.

The tables were converted in place: engine first, then character set, then database default. Each conversion was verified. This clears the schema-level obstacles and gives the tracker a foundation that supports either path forward.

The remaining question is the application layer itself: whether to adapt the existing MantisBT 1.1.8 source for PHP 8 compatibility, preserving the schema and behaviour, or to migrate the data forward to a supported MantisBT release. Both paths are viable. The database work completed here is common to both — it does not commit the project to either direction, and it removes a dependency on legacy defaults that would otherwise need fixing regardless of which route is chosen.

What the Outage Taught

The e1 outage was not caused by Cloudflare. It was not caused by Apache. It was not caused by the firewall, the fail2ban daemon, or the server's resource limits. It was caused by the interaction of three things: a missing HTTPS vhost, a blocked inbound port 80, and a Cloudflare mode that depended on the blocked port.

The lesson is simple and familiar: the platform is only as reliable as its least-visible dependency. A port forward. A DNS proxy setting. A virtual host that was never created because nobody needed it until they did. And, as sportkin's continued uptime showed, the choice of how DNS and delivery are architected is itself a reliability decision — one that determines which failures are even possible.

Sportkin has faced surges before — 437,000 requests in a day, worker limits raised from 150 to 250, capacity stretched and tested. Those moments showed where the system could grow. This one showed where it could break. Both kinds of knowledge matter.

Investigation complete. System restored. Onward.

#Sportkin #SKIZCorp #WebInfrastructure #Technology #SystemEngineering #Apache #Cloudflare #MantisBT #NS1 #DNS