🐛 Debugging a sneaky 502 Bad Gateway on production

Spent some time today chasing a frustrating bug on flowrecorder.com.
Everything worked fine on normal navigation. But the moment you hit browser reload on the dashboard — boom. 502 Bad Gateway from Cloudflare.

The symptoms:
Landing pages → perfectly fine on reload ✅
Dashboard & authenticated pages → 502 on every reload ❌
SSR was running, PHP-FPM was healthy, Nginx was up

The real culprit?
Two separate issues compounding each other:
1. Nginx FastCGI buffer too small The Nginx error log told the story:
upstream sent too big header while reading response header from upstream.
The default FastCGI buffer (4KB) couldn't handle the large response headers

2. Too much data in Inertia shared props.
The root cause of the large headers was sharing too much on every request.

The fix on nginx:
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;

The fix on the code side:
Cache the response and pass what is needed, not all the model data.

Lesson learned: Inertia's shared props travel in every response header. The dashboard had enough session data + shared props to exceed Nginx's buffer, but public pages didn't, which is why the bug only showed up behind authentication.
Always audit what you're sharing globally in Inertia Requests. Every key you add there gets sent on every single page load.

Building flowrecorder.com, a session recording and user journey tool.

Follow along for more real-world Laravel + Inertia learnings.