So, what's going on here?
This is for use on a local Nginx-based development environment for a Jetpack connected WordPress site (using Photon on a non-Jetpack-connected site is a violation of the WordPress.com terms of service).
What if the site you're working on has like, 30GB of image uploads? You certainly don't want to have to rsync those down just to dev on the site. You probably want this: images you upload to your local install work, and images that exist only on the production server also work. Well, that's what this does.
First, there is a location block that matches image files. It tries to grab the file from the local filesystem at $url. If that fails, it tries @photon, which is a named location block.
The @photon block attempts to rewrite resized images to use Photon for resizing (that way they'll work even if the particular resize you asked for doesn't exist on the production server). If it's not a resized image, it just 301s to Photon.
===
The config.yaml snippet contains these locations in a format that PuPHPet will understand. Merge these locations in with your existing ones in puphpet/config.yml.
===
Note that this assumes you are developing on your production domain (repointed locally in your hosts file). If you are not, just change $host to your production domain.
===
Why issue an HTTP redirect instead of proxy the request? Well, mostly because this is running on a local VM, and I want to close the connection as quickly as possible. It's a little more work for the browser, and a little less work for the VM.
¯\_(ツ)_/¯
===
Why not just proxy to the host site? Well, you'd have to hardcode in the IP address, because the domain is pointed at your local VM, remember? So that's annoying. Also, Photon is FAST, and CACHED, so it saves wear and tear on your production server. Also, it lets you request image sizes that don't exist on production (as in don't exist yet, or didn't ever exist).