Here's a list of "pitfalls" that are commonly used and really shouldn't: http://wiki.nginx.org/Pitfalls
I notice that you're using a lot of "if" statements. I hope you've read this http://wiki.nginx.org/IfIsEvil. I understand that in this case it might be harder to find alternatives for the if-statement, haven't looked into what you need really deeply.
The rtCamp configuration I linked to earlier makes use of try_files and says he has support for both supercache and domain mapping, so I think I'll migrate to that.
I really think Nginx in still underestimated by large. Most article handles rewrite in nginx based on their Apache knowledge.
Nginx's try_files is magical. So does maps{..} section.
Using Nginx map, you can server static files in WordPress-multisite without PHP (much better than X-SendFile or X-Accelredirection). On large wordpress-multisite network, this can really increase Nginx's capacity by multifold.
See - http://rtcamp.com/tutorials/nginx-maps-wordpress-multisite-s...
Edit 2: Actually I think WP Supercache is the one that changed.
Edit 3: This config looks more up-to-date than mine -- http://rtcamp.com/tutorials/nginx-wordpressmultisite-subdoma...
I particularly liked how they used the try_file directive to cut down on the if statements.
----
Like most people I've cobbled together what I found through Google searching. My case is further complicated because I run a multisite configuration and use the WP Domain Mapping plugin.
It works in a few stages.
WP Supercache is configured to gzip pages to disk. It used to be that you needed to add extra code by hand to support domain mapping, but WP Supercache now cooperates and puts on-disk cached files for each blog in its own directory.
Then I put specific directives in a sites-available/ config file, not the main Nginx file (I serve a static site off the same server).
First,
The default_server directive means that if another listen directive doesn't pick up an incoming request, it will be handled by this config. Otherwise multisite goes kerflooie.I like my logs to be divided by site, so:
Getting end-to-end UTF8 on a stack is a hassle because you have to do it in the database (multiple times, MySQL has about two hojillion charset configuration dials), in PHP and then in Nginx: Then the obvious: Now for the meat: The rewrite is just a little tweak. If you go to /wp-admin, Wordpress will often redirect to the home page. If you go to /wp-admin/, it does what you expect. So this rewrite just adds a trailing slash. For multisite, the Wordpress coders change the URLs files are served from, for reasons that are simply beyond my mortal comprehension. Anyhow, you need a rewrite rule for /files/ URLs: Then what follows is based on the common config file you'll see on a dozen blog and forum posts if you google around.The next thing to do is try and serve a file straight off disk. Nginx does things in an unintuitive order, so even though this rule is further down, it will often fire first:
The "break" directive basically says, "Oh you found whatever.css|jpg|js? Just serve that up kthxbai".Now we proceed to determine whether or not we'll try to serve a cached file off disk:
If there's still a supercache URL, we try to serve it straight off disk: Otherwise, give up and let Wordpress grind out the file: From the Wordpress wiki I picked up a few nifty directives to make log files a little less cluttered; I've thrown those in a common file which I include here: clean.conf looks like this: The final step is to add this magic directive to your master nginx.conf: This tells Nginx to look for a file with a .gz extension. So when it gets redirected to look at whatever-blog.com/index.html, it will also check for index.html.gz. If it finds that file, it will serve it instead.