Scaricare i siti web che utilizzano Envoy

Informazioni su Envoy

Envoy è nato per risolvere un problema all’interno del parco server di una singola azienda: troppi servizi che si chiamavano a vicenda attraverso una rete al cui interno nessuno riusciva a vedere. Classificato nella categoria Reverse proxies, il software è un proxy di livello applicativo che si colloca davanti ai servizi o tra di essi e gestisce bilanciamento del carico, nuovi tentativi, circuit breaking, instradamento del traffico e terminazione TLS, ed è il componente che molti prodotti di service mesh, ingress e API gateway usano come piano dati.

Nessuno che pubblichi un sito web sceglie Envoy come si sceglie un CMS. A sceglierlo è un team di piattaforma, oppure arriva sotto un gateway gestito, un prodotto API o una piattaforma di hosting acquistati per ragioni del tutto diverse. Rilevare il proxy su un dominio è quindi un segnale organizzativo più che tecnico. Dietro quel dominio c’è con ogni probabilità un backend orchestrato a container, un team che gestisce l’instradamento delle richieste come una disciplina a sé e un budget per l’infrastruttura che un cliente di hosting condiviso non ha.

Cloud Native Computing Foundation cura il progetto da quando lo ha ricevuto in dono dal team di ingegneri che lo aveva scritto, e la licenza Apache 2.0, insieme a un’implementazione in C++, ne fa qualcosa che i fornitori possono integrare e rivendere senza chiedere permesso, il che spiega in buona parte la sua diffusione. Rilasciato nel 2016, il proxy è diventato una risposta comune alla gestione del traffico tra servizi abbastanza in fretta da far sì che oggi il suo nome compaia all’interno di prodotti che non lo citano mai nel proprio marketing.

A ottobre 2026 rileviamo Envoy su 263.034 siti, di cui 162.900 attribuiti agli Stati Uniti, con una prevalenza di domini .com. La concentrazione in un solo paese riflette i luoghi in cui si concentra l’ingegneria cloud native e in cui i fornitori che integrano il proxy spingono di più le vendite, e probabilmente anche quelli in cui gli operatori sono meno propensi a prendersi la briga di rimuovere gli header di risposta identificativi.

L’ultimo punto merita di essere detto chiaramente invece che nascosto. Qui il rilevamento procede per deduzione. Leggiamo le firme negli header di risposta e le impronte delle pagine di errore che il proxy emette per impostazione predefinita, e qualsiasi operatore può rinominarle o rimuoverle con una riga di configurazione. I siti che si trovano dietro una rete di distribuzione dei contenuti che termina per prima la connessione potrebbero non rivelare affatto il proxy. Il conteggio registrato è una stima per difetto, e un riscontro indica che il proxy ha risposto, non se il team lo gestisce in proprio o lo ha ereditato all’interno di un prodotto gestito, una distinzione che dall’esterno non siamo in grado di fare.

Per i fornitori di infrastruttura, osservabilità e sicurezza, il valore dell’elenco sta nel fatto che identifica le organizzazioni in base a come operano più che a ciò che pubblicano. Una singola ricerca conferma un header su un dominio. Una popolazione permette di dimensionare l’insieme raggiungibile dei team di piattaforma, di mettere in relazione il proxy con i cloud e i framework accanto a cui compare e di osservare come quell’insieme cresce o si sposta da un aggiornamento all’altro, ed è proprio questa la domanda che si pone davvero chiunque venda nel mercato dell’infrastruttura cloud native.