Configurazione del Proxy Inverso

Usare un proxy inverso è una pratica comune. Le seguenti configurazioni sono le più consigliate e usate.

Importante, le intestazioni sono considerate per risolvere il pubblico e sono X-Forwarded-Proto per il protocollo e Host per il dominio, sei pregato di includerle nella tua configurazione.

Apache

Apache e mod_proxy dovrebbero non decodificare/codificare gli slash e lasciarli come sono:

Per installare al percorso relativo, /npm, sul server

<VirtualHost *:80>
  AllowEncodedSlashes NoDecode
  ProxyPass /npm http://127.0.0.1:4873 nocanon
  ProxyPassReverse /npm http://127.0.0.1:4873
</VirtualHost>

Per installare al percorso di root, /, sul server

<VirtualHost *:80>
  ServerName tuo.dominio.com
  ServerAdmin ciao@tuo.dominio.com
  ProxyPreserveHost On
  AllowEncodedSlashes NoDecode
  ProxyPass / http://127.0.0.1:4873/ nocanon
  ProxyPassReverse / http://127.0.0.1:4873/
</VirtualHost>

Configurazione con SSL

Configurazione del server virtuale di Apache.

    <IfModule mod_ssl.c>
    <VirtualHost *:443>
        ServerName npm.your.domain.com
        SSLEngine on
        SSLCertificateFile      /etc/letsencrypt/live/npm.your.domain.com/fullchain.pem
        SSLCertificateKeyFile   /etc/letsencrypt/live/npm.your.domain.com/privkey.pem
        SSLProxyEngine          On
        ProxyRequests           Off
        ProxyPreserveHost       On
        AllowEncodedSlashes     NoDecode
        ProxyPass               /       http://127.0.0.1:4873/ nocanon
        ProxyPassReverse        /       http://127.0.0.1:4873/
        RequestHeader set       X-Forwarded-Proto "https"
    </VirtualHost>
    </IfModule>

Codice di controllo non valido

Talvolta, la compressione gzip può creare problemi con la richiesta eseguendo npm install e risultare in messaggi d'errore come questo:

npm WARN tar TAR_ENTRY_INVALID errore del codice di controllo
npm WARN tar zlib: controllo dei dati errato

Una possibile soluzione può essere disabilitare la compressione gzip per l'host virtuale, aggiungendo questo alla tua configurazione:

SetEnv no-gzip 1

Risultante in una configurazione simile a questa:

<VirtualHost *:80>
  AllowEncodedSlashes NoDecode
  SetEnv no-gzip 1
  ProxyPass /npm http://127.0.0.1:4873 nocanon
  ProxyPassReverse /npm http://127.0.0.1:4873
</VirtualHost>

Dovresti aggiungerlo solo alla configurazione del tuo host virtuale, se stai sperimentando il problema.

Nginx

Il seguente frammento è un esempio completo di docker, testabile nella nostra repository di esempi di Docker.

upstream verdaccio_v4 {
    server verdaccio_relative_path_v4:4873;
    keepalive 8;
}

upstream verdaccio_v4_root {
    server verdaccio_relative_path_v4_root:8000;
    keepalive 8;
}

upstream verdaccio_v3 {
    server verdaccio_relative_path_latest_v3:7771;
    keepalive 8;
}

server {
    listen 80 default_server;
    access_log /var/log/nginx/verdaccio.log;
    charset utf-8;

    location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_set_header X-NginX-Proxy true;
      proxy_pass http://verdaccio_v4_root;
      proxy_redirect off;
    }

    location ~ ^/verdaccio/(.*)$ {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_set_header X-NginX-Proxy true;
      proxy_pass http://verdaccio_v4/$1;
      proxy_redirect off;
    }

    location ~ ^/verdacciov3/(.*)$ {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $host;
      proxy_set_header X-NginX-Proxy true;

      proxy_pass http://verdaccio_v3/$1;
      proxy_redirect off;
    }
}

Esempio di SSL

server {
    listen 80;
    return 302 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name localhost;

    ssl_certificate     /etc/nginx/cert.crt;
    ssl_certificate_key /etc/nginx/cert.key;

    ssl on;
    ssl_session_cache  builtin:1000  shared:SSL:10m;
    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_set_header    Host $host;
        proxy_set_header    X-Real-IP $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header    X-Forwarded-Proto $scheme;
        proxy_pass          http://verdaccio_v4_root;
        proxy_read_timeout  600;
        proxy_redirect off;
    }

    location ~ ^/verdaccio/(.*)$ {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass http://verdaccio_v4_root/$1;
        proxy_redirect off;
    }
}

Esecuzione dietro proxy inverso con dominio e porta differente

Sottocartella

Se l'intero URL è in uso per Verdaccio, non devi definire un url_prefix, altrimenti, necessiteresti di qualcosa del genere nel tuo config.yaml.

url_prefix: /sub_directory/

Se esegui Verdaccio dietro proxy inverso, potresti notare tutti i file di risorse serviti come percorso relativo, come http://127.0.0.1:4873/-/static

Per risolvere questo problema, dovresti inviare il dominio e la porta reali a Verdaccio con l'intestazione Host

La configurazione di Nginx dovrebbe somigliare a questa:

location / {
    proxy_pass http://127.0.0.1:4873/;
    proxy_set_header Host            $host:$server_port;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

Per questo caso, l'url_prefix NON dovrebbe esser impostato nella configurazione di Verdaccio

---

o nell'installazione di una cartella secondaria:

location ~ ^/verdaccio/(.*)$ {
    proxy_pass http://127.0.0.1:4873/$1;
    proxy_set_header Host            $host:$server_port;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}

In questo caso, l'url_prefix dovrebbe esser impostato a /verdaccio/

Nota: C'è uno slash dopo il percorso d'installazione (https://your-domain:port/verdaccio/)!

Sovrascrivere l'url pubblico

Dalla verdaccio@5.0.0

Il nuovo VERDACCIO_PUBLIC_URL è inteso all'uso dietro proxy, questa variabile sarà usata per:

• Usata come percorso di base per servire risorse dell'UI come (js, favicon, etc.)
• Usata alla restituzione del percorso di base dist dei meta-dati
• Ignora le intestazioni host e X-Forwarded-Proto
• Se url_prefix è definito sarà messo in attesa alla variabile env.

VERDACCIO_PUBLIC_URL='https://somedomain.org';
url_prefix: '/my_prefix'

// url -> https://somedomain.org/my_prefix/

VERDACCIO_PUBLIC_URL='https://somedomain.org';
url_prefix: '/'

// url -> https://somedomain.org/

VERDACCIO_PUBLIC_URL='https://somedomain.org/first_prefix';
url_prefix: '/second_prefix'

// url -> https://somedomain.org/second_prefix/'