Journey through the Bad gateway - a valet workaround

Today I had to make a small change to a legacy project. It’s a long living application running on the CodeIgniter framework. The first thing a developer does is to pull the codebase and get the app to run locally. In my normal setup, I use Valet to serve my local projects. Valet is a small development environment that helps us develop PHP projects by serving the project locally without needing to resort to big virtual machines to simulate UNIX-based systems etc. I highly recommend looking into Valet if you’re on a mac and developing PHP projects.
Geschreven door Philippe Damen

502 what?

Valet usually works fine out of the box but now I ran into some strange issues trying to get it to work in my local development environment. So I pull the repo and go to the Valet URL. And it works! No problems here.
Except when we try to do anything in the admin. Going through the admin panel gave a 502 bad gateway after a few requests. Also, some of the pages that worked before didn’t respond anymore.
So I went digging. ‘Valet 502 error’ didn’t seem to ring a bell with Google so I went looking in the Valet code for some log files.
I found out that Valet has a log folder. The place to be if you should ever want to trace valet related errors, so be sure to look into your local ~/.valet/Log folder. There you can find the web server related error and access logs. In the error.log file, I saw the notable error “upstream sent too big header …”.

upstream sent too big header while reading response header from upstream


I had no idea what this meant or why this only happened in our CodeIgniter project so next step? Back to Google! After a couple of minutes investigating the issue, I found something that looked like the same problem with a way to solve it.
This particular user
said he managed to fix the issue by adding the following lines to the Valet.conf file.

fastcgi_buffers 16 16K;

fastcgi_buffer_size 32K;


Worth a shot right? But he didn’t mention where this file would be.
There I went, down the rabbit hole for what must’ve been more than an hour until I got so frustrated I called one of my colleagues to explain the issue I was running into and hopefully shed some light. Turns out the changes need to occur in the globally installed composer package as opposed to the .valet folder.

½ solution

So next step was to locate the globally installed composer files. This was easily found at /usr/local/etc/nginx/Valet/Valet.conf.I pulled up the post with the lines to add to the config file.
One user
said to add the following lines to the “location ~\php$” block. It ended up looking like this:

location ~ \.php$ {

fastcgi_split_path_info ^(.+\.php)(/.+)$;

fastcgi_pass unix:/Users/{username}/.valet/valet.sock;

fastcgi_index /Users/{username}/.composer/vendor/laravel/valet/server.php;

include fastcgi_params;

fastcgi_param SCRIPT_FILENAME /Users/{username}/.composer/vendor/laravel/valet/server.php;

fastcgi_buffers 16 16k;

fastcgi_buffer_size 32k;

}


At this point I was over the moon. Finally I had found a solution and I could start working on my actual task.
So I tab back to the web page and hit refresh.
*dramatic pause*
And… 502 bad gateway. The exact same.
Nginx restart, Valet restart, PHP restart, nothing changed anything.
So what went wrong? I was pretty sure this was supposed to work, so why didn’t it?

The last stretch

I started scrolling through the Valet issue pages to see if someone mentioned anything that would help me out or trigger something. After about 10 min of scrolling I found a mention about the Nginx folder in the hidden .valet folder we talked about earlier. Apparently Valet creates a config file for each site based on that Valet.conf file we just made some changes to and places it in .Valet/nginx/ .
If a file for that site already exists Valet doesn’t bother checking if the base config file has changed.
Makes sense since this is core code and we shouldn’t be editing them. Whoops. So I updated the relevant config file at /Users/{username}/.valet/Nginx/{site}.dev with the code above. Of course don’t forget to restart the Nginx service and Valet like this (sudo may or may not be needed here):

brew services restart nginx && Valet restart


This assumes you have Nginx installed through brew. If you didn’t install Nginx yourself Valet will have installed it using brew so the command above should do the trick.
And there it is. Browsing to the admin now works as expected!

Lessons learned

Finally, what a journey. In the end this little issue cost me about 4 hours to figure out. But we got there. So what did I learn? I have a much better grasp on what Valet actually does behind the scenes and one more thing, something I already knew but this situation re-affirms it.
If you’re stuck on something, you’re going to be staring yourself blind trying to find the solution. And something simple like explaining your issue to someone who has no idea what’s going on can help a lot in clearing the fog out of your mind and help you see clearly again.