J'ai enfin écrit une configuration nginx propre pour avoir un site statique et une appli php séparée dans un même vhost. Avant, j'utilisais un lien symbolique.. Mais il faut dire que ce ne fût pas trivial d'y parvenir. Voici ma config :

server {
        ...
        root /var/www/jeekajoo.eu;
        index index.html index.htm index.php;

        location / {
                access_log /var/log/nginx/jeekajoo.eu_access.log;
                error_log /var/log/nginx/jeekajoo.eu_error.log;
                try_files $uri $uri/ =404;
        }

        location /links {
                access_log /var/log/nginx/shaarli_access.log;
                error_log /var/log/nginx/shaarli_error.log;
                alias /var/www/shaarli;
                try_files $uri $uri/ @shaarli;
                location ~ \.php$ {
                        include conf.d/phpfpm;
                        fastcgi_param SCRIPT_FILENAME $request_filename;
                }
        }

        location @shaarli {
                rewrite /links/(.*)$ /links/index.php?/$1 last;
        }
}

2 changements majeurs par rapport à la configuration de l'auteur de l'article :

• J'ai viré le /index.php$is_args$args dans le try_files de location / {} et je l'ai remplacé par =404 qui sera la réponse de nginx si aucune ressource n'est trouvée.
• J'ai viré le bloc location ~ \.php$ {} qui n'est pas non plus nécessaire pour un site statique.

Ça donne ça :

• /** => /var/www/jeekajoo.eu : servi exclusivement par nginx.
• /links/** => /var/www/shaarli : servi par nginx et php-fpm.

Ça peut notamment aider à utiliser de bonnes pratiques dans la configuration de nginx.

Dans le cas de l'hébergement d'un wordpress via un reverse proxy, rajouter cela dans le wp-config.php:
"""
define('FORCE_SSL_ADMIN', true);
if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https')
$_SERVER['HTTPS']='on';
"""
Bien penser à envoyer le header 'HTTP_X_FORWARDED_PROTO' depuis le serveur web qui proxify.
Pour ma part c'est un nginx qui renvoie les requêtes vers un LXC (appelé ici nochiefs (qui est une entrée dans mon /etc/hosts qui pointe sur une IP bridgée)) à base de apache / mod_php / mariadb. Extrait de ma conf nginx:
"""
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme; # <--- là
proxy_pass http://nochiefs;
}
"""
En gros ça fait:
navigateur --> interface réseau du serveur hôte --> NGINX qui fait le SSL offloading et proxypass --> interface réseau bridgée sur le host pour le LXC ---> APACHE en clair (HTTP) ----> Wordpress

<publicité>
Résultat: https://nochiefs.net en concert prochainement dans le 44 et le 85
</publicité>

petite ruse pour faire résoudre l'entrée dns du backend vers lequel on renvoie les requêtes.
directives: proxy_pass + resolver

"""
Nginx HTTP server boilerplate configs

Nginx Server Configs is a collection of configuration snippets that can help your server improve the web site's performance and security, while also ensuring that resources are served with the correct content-type and are accessible, if needed, even cross-domain.
"""
Beau projet.

"""
(...)
But the asynchronous, event-driven approach still has a problem. Or, as I like to think of it, an “enemy”. And the name of the enemy is: blocking. Unfortunately, many third-party modules use blocking calls, and users (and sometimes even the developers of the modules) aren’t aware of the drawbacks. Blocking operations can ruin NGINX performance and must be avoided at all costs.

Even in the current official NGINX code it’s not possible to avoid blocking operations in every case, and to solve this problem the new “thread pools” mechanism was implemented in NGINX version 1.7.11. What it is and how it supposed to be used, we will cover later. Now let’s meet face to face with our enemy.
"""

docker run --name wp-mysql -d -e MYSQL_ROOT_PASSWORD=toor mysql
docker run --name wp-web -d -e VIRTUAL_HOST=wordpress.10.5.0.127.xip.io --link wp-mysql:mysql wordpress
docker run --name nginx-proxy -d -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock jwilder/nginx-proxy

• remplacer 10.5.0.127 par l'ip de votre HOST
• accèder au wordpress via http://wordpress.10.5.0.127.xip.io
• tout cela est possible grâce à https://github.com/jwilder/nginx-proxy qui lui même s'appuie sur docker-gen https://github.com/jwilder/docker-gen

quelques exemples d'utilisations de ngx_lua

enfin, rien ne vaut cette doc: http://wiki.nginx.org/HttpLuaModule

lister les modules nginx:
2>&1 nginx -V | tr ' ' '\n'

(edité)

moi j'utilise des scripts d'init de la doc officielle: http://munin-monitoring.org/wiki/MuninConfigurationMasterCGI
cette tambouille s'appuie sur le paquet debian 'spawn-fcgi'

compléments: http://munin.readthedocs.org/en/latest/example/index.html

Mozilla's SSL config generator pour apache, nginx et haproxy.

une jolie doc nginx

"""
The problem : be able to cache a backend response if it took more than 5 seconds. If not, don't cache it!
"""
il utilise un map sur le temps de réponse + 2 vhosts + la directive X-Accel-Expires

bon, suite à ça: https://jeekajoo.eu/links/?mMofTA

j'ai gruiké mon vhost shaarli comme ceci:
location /links {
set $query_string_new $query_string;
if ($query_string = do=rss ) {
set $query_string_new do=rss&searchtags=river;
}
if ($query_string = do=atom ) {
set $query_string_new do=atom&searchtags=river;
}
index index.php;
}
location ~ .php$ {
include conf.d/phpfpm;
fastcgi_param QUERY_STRING $query_string_new;
}

désormais:
https://jeekajoo.eu/links/?do=rss pointe sur https://jeekajoo.eu/links/?do=rss&searchtags=river
https://jeekajoo.eu/links/?do=atom pointe sur https://jeekajoo.eu/links/?do=atom&searchtags=river

cela veut dire que pour qu'un shaarlink se retrouve spécifiquement sur shaarli.fr ou autre shaarli-river, il faudra que je tag spécifiquement avec 'river'

si vous êtes fan de moi (^^') et que vous voulez les flux complets, vous rajoutez un slash (oui j'avais prévenu que c'était 'gruik')
https://jeekajoo.eu/links/?do=rss/
https://jeekajoo.eu/links/?do=atom/

voilà.

Certaines appplications comme cozycloud s'appuient sur les websockets.
pour activer leur support sur nginx, rajouter ces 3 headers dans le 'location' qui fait le proxy_pass:
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

source: https://twitter.com/jeekajoo/status/469448309267259392

utiliser la commande suggérée dans le commentaire:
$ printf "${username}:openssl passwd -apr1\n" >> .htpasswd
remplacer ${username} par votre nom d'utilisateur.
le mot de passe sera demandé en intéractif pour éviter qu'il fuite dans votre ~/.bash_history

Sur nginx, il est possible de forger des réponses HTTP via la directive echo (http://wiki.nginx.org/HttpEchoModule).
La directive echo prend également des variables comme $remote_addr (adresse ip distante) ,$http_user_agent, $http_referer... et plein d'autres.
Cela ouvre le champ à beaucoup de choses simplement.
Le site remoteaddr.info est par exemple exclusivement basé sur des echo nginx: aucune page html en dur, tout est dans la conf nginx.

difficile de faire plus complet