Une petite expérimentation a montré que pour mon usage, nginx est un excellent proxy de mise en cache. Tellement bien que je me suis demandé ce qui pourrait arriver si je commençais à enchaîner les serveurs ensemble (proxy A —> proxy B —> nginx serveur C, sur tout HTTPS/SSL).

La réponse a été… 502 Mauvaises erreurs de passerelle (502 Bad Gateway).

Je l’avais mis en place et j’ai ensuite utilisé Integrity by PeacockMedia (logiciel gratuit/donateur sur le Mac App Store) pour tester le site. Si vous n’en avez jamais entendu parler, Integrity est une sorte de vérificateur de liens brisés pour macOS – rapide et très facile à utiliser. Quoi qu’il en soit… il a immédiatement généré un tas de 502 erreurs pour les versions HTTPS du site.

Je l’ai vérifié en essayant de charger manuellement une page par HTTPS dans un navigateur web, et bien sûr, l’erreur 502.

——

En fait, mon problème était que je venais de passer d’un simple proxy_pass https://123.45.67.89; dans l’emplacement à tout le truc de « upstream backend », avec quelque chose comme ça :

upstream backend {
     server 123.45.67.89;
     server 12.34.56.789 backup;
}
server {
     listen 443;
     server_name example.com;
     location / {
         proxy_pass https://backend;
     }
}
 

Cela ne fonctionne pas tout à fait, et la raison en est que vous devez spécifier le port dans la section « upstream backend » si ce n’est pas le port 80. Il ne suffit pas que la ligne proxy_pass commence par https – je dois aussi lui dire explicitement d’utiliser le port 443.

La version de travail était donc bien sûr la suivante :

upstream backend-ssl {
     server 123.45.67.89:443;
     server 12.34.56.789:443 backup;
}
server {
     listen 443;
     server_name example.com;
     location / {
         proxy_pass https://backend-ssl;
     }
}
 

Cela ne veut pas dire que c’est la seule cause des 502 erreurs commises avec le proxy de mise en cache de nginx (les dépassements de délais sont une autre cause fréquente d’après ce que j’ai compris).

Mais si vous venez d’implémenter le bit en amont, il vaut la peine de vérifier si vous avez le même problème.

Si ce n’est pas le cas, il vaut la peine de jeter un coup d’oeil à votre journal d’erreurs pour aider à réduire les possibilités. Il se trouve généralement dans votre répertoire logs : si vous utilisez Ubuntu /var/log/nginx/error.log c’est là qu’il se trouve souvent.