Summary

On 24 August 2026, kulinaryos.com and www.kulinaryos.com temporarily returned 502 Bad Gateway. DNS remained correct and authoritative throughout the incident. The application, ERP, operations site and email were not affected.

We apologise for the interruption and for the impact on access to the institutional website.

What happened

The RBX edge could no longer establish HTTP or HTTPS connections to the legacy WordPress origin. Tests from independent networks continued to reach the origin, while the RBX ingress address—and later an initial relay address—received source-specific connection refusals.

This evidence is consistent with a firewall, Fail2ban, hosting control panel or provider-level rule at or in front of the origin. The exact blocking component is not yet confirmed because RBX does not currently have administrative access to the origin logs and security controls.

This was not a DNS failure and it was not caused by a lack of capacity in RBX infrastructure.

Recovery

Service was restored with this temporary, controlled path:

Internet → RBX Traefik edge → internal RBX Nginx relay → legacy WordPress origin

Traefik remains the public edge, TLS endpoint and router. Nginx is used only as an internal egress relay. Its health check is local and upstream connections are reused, avoiding unnecessary active probes against the legacy origin.

After recovery, authoritative DNS, public resolvers, TLS and the main web endpoints were validated successfully.

Prevention plan

  • Obtain authorised administrative access to the origin and review Plesk, firewall, Fail2ban and provider logs.
  • Allow-list the documented RBX ingress and relay addresses and verify that neither path can be blocked by automated rules.
  • Add source-aware reachability checks and alerts for upstream connection refusal, without aggressive origin probing.
  • Keep a tested relay fallback and a documented recovery and rollback runbook.
  • Prepare a controlled migration or replica of the institutional WordPress installation in infrastructure owned by Kulinaryos or managed by RBX, reducing dependence on an opaque legacy origin.
  • Complete a post-incident review and record the confirmed root cause when origin evidence becomes available.

Monitoring

The post-incident monitoring window has been extended to 72 hours from service recovery. DNS delegation, authoritative records, public resolvers, HTTPS, the relay and the unaffected application services will remain under observation. Any regression will be reported here.