Nginx fonctionnant en tant que proxy pour une backend HTTPS fonctionne parfaitement. Le problème que j'ai rencontré en faisant cela était lié aux requêtes envoyées au serveur proxifié depuis Nginx n'ayant pas le bon SNI (pour SSL) ni l'en-tête HTTP Host
qui, selon le serveur backend proxifié, sont généralement requis.
Vous aurez probablement besoin de quelques lignes supplémentaires dans votre configuration Nginx :
# Envoyer les informations SNI sur la requête SSL afin que le backend puisse utiliser les bonnes clés.
proxy_ssl_server_name on;
# Domaine SSL SNI à demander au backend
proxy_ssl_name backend.example.com;
# Si vous utilisez l'hébergement virtuel basé sur l'hôte, vous devrez ajouter l'en-tête HTTP `Host` :
proxy_set_header Host backend.example.com;
# Facultatif. Assurez-vous que la connexion Nginx <-> Backend utilise le HTTPS sécurisé
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
C'est ce que j'utilise. Cela semble fonctionner mais cela pourrait ne pas être plus rapide. Il y a probablement quelques ajustements des paramètres de mise en cache qui sont nécessaires mais la connexion principale aux vrais backends fonctionne.
proxy_cache_path /var/cache/nginx/mirror use_temp_path=off keys_zone=mirror:10m max_size=90g inactive=1y levels=1:1:1;
server {
server_name mirror.example.com;
listen 80;
listen [::]:80;
# Let's Encrypt
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/lib/letsencrypt/webroot;
}
location = /.well-known/acme-challenge/ {
return 404;
}
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/letsencrypt/live/mirror.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mirror.example.com/privkey.pem;
# Indiquer au serveur distant/backend quel client fait réellement la requête
#proxy_set_header X-Real-IP $remote_addr;
#proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# Activer la plage. Si vous proxy de gros fichiers, vous pouvez les diviser en morceaux pour permettre des recherches arbitraires plus rapides
#proxy_cache_key $uri$is_args$args$slice_range;
#proxy_set_header Range $slice_range;
#slice 100m;
# Garder notre cache à jour
#proxy_cache_use_stale updating;
proxy_ignore_client_abort on;
# Empêcher les mises à jour de cache concurrentes multiples en bloquant les nouveaux clients jusqu'à ce que la demande du backend soit remplie.
proxy_cache_lock on;
proxy_cache_lock_age 35m;
proxy_cache_lock_timeout 35m;
# Configuration SSL du serveur distant backend
proxy_ssl_verify on;
proxy_ssl_trusted_certificate /etc/ssl/certs/ca-certificates.crt;
proxy_ssl_server_name on;
# Doit correspondre au nom de notre configuration de cache proxy
proxy_cache mirror;
# Nettoyer automatiquement le cache
#proxy_cache_purge $purge_method;
# Proxyer le backend de Raspbian avec le bloc Nginx `upstream`
location /raspbian {
# HTTP c'est bien, non ?
proxy_pass http://raspbian;
# Forcer la connexion HTTPS au backend, même si les clients nous demandent sur HTTP
#proxy_pass https://raspbian;
# Utiliser le même schéma que nos clients. (Pourquoi ??)
#proxy_pass $scheme://raspbian;
# Utiliser la source Raspbian
proxy_set_header Host raspbian.raspberrypi.org;
proxy_ssl_name raspbian.raspberrypi.org;
}
# Proxyer le backend Ubuntu avec le bloc Nginx `upstream`
location /ubuntu {
proxy_pass http://ubuntu;
proxy_set_header Host us.archive.ubuntu.com;
proxy_ssl_name us.archive.ubuntu.com;
# Utiliser le miroir de DigitalOcean à la place, par exemple
#proxy_pass http://digitalocean;
#proxy_set_header Host mirrors.digitalocean.com;
#proxy_ssl_name mirrors.digitalocean.com;
}
# On pourrait probablement être sophistiqué avec des contrôles de durée de vie plus granulaires pour les entrées de cache basées sur l'URL.
proxy_cache_valid 200 206 1w;
}
upstream raspbian { server raspbian.raspberrypi.org; }
upstream ubuntu { server us.archive.ubuntu.com; }
upstream digitalocean { server mirrors.digitalocean.com; }