# Svantaggi nel proxy tramite porta invece di socket di dominio Unix?
**URL:** https://meta.discourse.org/t/any-downsides-to-proxy-via-port-instead-of-unix-domain-socket/240359
**Category:** Self-hosting
**Created:** [29 Settembre 2022, 2:11am UTC](https://meta.discourse.org/t/any-downsides-to-proxy-via-port-instead-of-unix-domain-socket/240359 "2022-09-29T02:11:26Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [29 Settembre 2022, 2:11am UTC](https://meta.discourse.org/t/any-downsides-to-proxy-via-port-instead-of-unix-domain-socket/240359/1 "2022-09-29T02:11:26Z")
Sto testando il deployment di Discourse su AlmaLinux 9 derivato da CentOS con SELinux abilitato e nginx esterno configurato.
Poiché il container basato su Ubuntu non conosce SELinux, ogni volta che avvio il container, sostituisce continuamente il socket di dominio Unix con un nuovo file non etichettato a livello di sicurezza, e nginx non è autorizzato a comunicare con esso finché non eseguo `restorecon` sul file per dargli un contesto di sicurezza a cui nginx è autorizzato ad accedere. Ovviamente, questa non è una soluzione di produzione.
Non voglio davvero eseguire `semanage permissive -a httpd_t` perché vorrei effettivamente sfruttare SELinux sull’unico servizio effettivamente esposto al mondo esterno. ☺
Funziona se faccio il proxy verso una porta di rete invece che verso un socket di dominio Unix:
- `setsebool -P httpd_can_network_connect 1`
- non usare `templates/web.socketed.template.yml`
- `expose: - "8008:80"`
- Nel nginx esterno, `proxy_pass http://127.0.0.1:8008`
Ci sono svantaggi particolari in questo? Dovrei cambiare qualche parametro come il limite di connessione in questa configurazione?
Scriverò questo in modo più dettagliato come documentazione dopo test più approfonditi e, se ci saranno ulteriori preoccupazioni, potrò includerle in ciò che scriverò.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [29 Settembre 2022, 2:14am UTC](https://meta.discourse.org/t/any-downsides-to-proxy-via-port-instead-of-unix-domain-socket/240359/2 "2022-09-29T02:14:34Z")
Finché blocchi le persone dall’accedere direttamente alla porta 8008 con il tuo metodo preferito, nessun problema.
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [29 Settembre 2022, 2:27am UTC](https://meta.discourse.org/t/any-downsides-to-proxy-via-port-instead-of-unix-domain-socket/240359/3 "2022-09-29T02:27:20Z")
Grazie!
```plaintext
public (active)
target: default
...
services: dhcpv6-client http https ssh
ports:
protocols:
forward: yes
masquerade: yes
forward-ports:
source-ports:
icmp-blocks:
rich rules:
```
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [29 Settembre 2022, 2:59am UTC](https://meta.discourse.org/t/any-downsides-to-proxy-via-port-instead-of-unix-domain-socket/240359/4 "2022-09-29T02:59:07Z")
C’è una differenza di latenza, un socket è circa 3 volte più veloce di una porta di loopback locale.
Detto questo, stiamo parlando di una differenza di 4-5us qui, nel migliore dei casi.
---
### Author:  [@mcdanlj](https://meta.discourse.org/u/mcdanlj)
#### Post date: [29 Settembre 2022, 11:52am UTC](https://meta.discourse.org/t/any-downsides-to-proxy-via-port-instead-of-unix-domain-socket/240359/5 "2022-09-29T11:52:02Z")
Dopo aver approfondito la questione, voglio assolutamente aggiungere `proxy_set_header \"Connection\" \"\";` per disabilitare l’header `Connection: close` predefinito.