Torna al blog

Come Funziona un Server Proxy: Spiegazione Chiara per Principianti

Aggiornato: Gennaio 2025 | Tempo di lettura: 17 minuti | Livello: Avanzato

📅13 novembre 2025

🔄 Cos'è un server proxy

Un Server Proxy (Proxy Server) è un server intermedio che funge da mediatore tra un client (il tuo dispositivo) e il server di destinazione. Quando utilizzi un proxy, le tue richieste non vanno direttamente al sito web, ma passano prima attraverso il server proxy, che le inoltra poi alla destinazione.

Concetto di base del funzionamento

SENZA PROXY (connessione diretta):
┌──────────┐                                    ┌──────────┐
│  Client  │ ────────── richiesta diretta ──────→│  Server  │
│  (Tu)    │ ←───────── risposta diretta ────────│ (Sito)   │
└──────────┘                                    └──────────┘
   IP: 192.168.1.10                                IP: 93.184.216.34

CON PROXY (tramite intermediario):
┌──────────┐           ┌──────────┐           ┌──────────┐
│  Client  │ ─────────→│  Server  │ ─────────→│  Server  │
│  (Tu)    │           │  Proxy   │           │ (Sito)   │
│          │ ←─────────│          │ ←─────────│          │
└──────────┘           └──────────┘           └──────────┘
   IP: 192.168.1.10      IP: 203.0.113.45       IP: 93.184.216.34

Il server vede l'IP del proxy (203.0.113.45), non il tuo IP!

A cosa serve un server proxy?

🔒 Sicurezza e anonimato

Nasconde il tuo indirizzo IP reale dai server di destinazione, rendendoti anonimo su Internet.

🌍 Bypass delle restrizioni geografiche

Permette di accedere a contenuti limitati da restrizioni geografiche.

⚡ Prestazioni

La memorizzazione nella cache dei contenuti richiesti di frequente riduce il carico e accelera il caricamento.

🛡️ Filtraggio del traffico

I proxy aziendali bloccano contenuti indesiderati e proteggono dalle minacce.

⚖️ Bilanciamento del carico

Distribuisce le richieste in entrata tra più server per aumentare l'affidabilità.

🔍 Monitoraggio e logging

Traccia tutte le richieste per analisi, sicurezza o conformità alle policy.

💡 Principale differenza con VPN

Il proxy opera a livello di applicazione (ad esempio, solo il browser), mentre la VPN crittografa tutto il traffico del dispositivo a livello di rete. Il proxy è più veloce e flessibile, la VPN è più sicura per tutto il traffico.

🎭 Il ruolo del proxy come intermediario

Il server proxy svolge il ruolo di intermediario intelligente tra il client e il server. Non si limita a inoltrare i dati, ma elabora attivamente richieste e risposte, prendendo decisioni su come gestirle.

Funzioni del proxy come intermediario

1. Modifica delle richieste

Il proxy può modificare gli header HTTP prima di inviare la richiesta al server di destinazione:

  • User-Agent: Modifica le informazioni sul browser (può fingersi Chrome invece di Firefox)
  • X-Forwarded-For: Aggiunge informazioni sull'IP reale del client
  • Accept-Language: Cambia la lingua preferita del contenuto
  • Referer: Nasconde o sostituisce la fonte del traffico

2. Verifica delle policy di accesso

Il proxy verifica se l'accesso alla risorsa richiesta è consentito in base a:

  • Indirizzo IP del client (whitelist/blacklist)
  • Autenticazione (login/password, token)
  • Ora del giorno (accesso ai social solo dopo il lavoro)
  • Categoria di contenuto (blocco giochi, pornografia, torrent)

3. Caching del contenuto

Il proxy salva copie delle risorse richieste di frequente (immagini, CSS, JavaScript) e le fornisce dalla cache, senza contattare il server. Questo risparmia traffico e accelera il caricamento del 50-90%.

4. Modifica delle risposte

Il proxy può modificare il contenuto prima di inviarlo al client:

  • Compressione del contenuto (gzip, brotli) per risparmiare traffico
  • Blocco di pubblicità e tracker
  • Aggiunta/rimozione di header di sicurezza
  • Iniezione di script (ad esempio, per l'analisi aziendale)

5. Logging e analisi

Il proxy registra informazioni su ogni richiesta: chi, quando, dove è stato richiesto, quanti dati sono stati trasferiti. Questo viene utilizzato per:

  • Monitoraggio dell'utilizzo del traffico
  • Rilevamento di anomalie e attacchi
  • Conformità alle policy aziendali
  • Debug e diagnostica dei problemi

⚙️ Tre modalità operative del proxy

🔵 Passthrough (Modalità di passaggio)

Il proxy inoltra semplicemente i dati senza modifiche. Minima elaborazione, massima velocità.

🟢 Intercepting (Modalità di intercettazione)

Il proxy analizza e modifica attivamente richieste/risposte. Utilizzato per filtraggio, ottimizzazione, sicurezza.

🟡 Hybrid (Modalità ibrida)

Il proxy decide per ogni richiesta se inoltrarla così com'è o elaborarla. Ad esempio, memorizza nella cache solo i file statici e inoltra direttamente le API.

🔄 Schema richiesta-risposta tramite proxy

Analizziamo in dettaglio cosa succede in ogni fase quando si richiede una pagina web tramite un server proxy.

Schema passo-passo del funzionamento del proxy

Passo 1: Il client invia la richiesta al proxy

GET http://example.com/page.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
Proxy-Authorization: Basic dXNlcjpwYXNz
Connection: keep-alive

↓ La richiesta va al server proxy (non direttamente a example.com)

Il client è configurato per utilizzare il proxy, quindi anche per la richiesta a example.com la connessione viene stabilita con il server proxy.

Passo 2: Il proxy riceve e verifica la richiesta

Il server proxy esegue una serie di controlli:

  • Autenticazione: Verifica login/password nell'header Proxy-Authorization
  • Autorizzazione: Questo utente può accedere a example.com?
  • Filtraggio: Il dominio example.com è bloccato dalla policy?
  • Cache: Esiste una copia valida di /page.html nella cache?

Passo 3A: Se presente in cache, restituisce immediatamente

✅ CACHE HIT — Trovato in cache!

HTTP/1.1 200 OK
Content-Type: text/html
Age: 120
X-Cache: HIT from proxy-server

<html>...contenuto della pagina...</html>

↑ Il proxy restituisce il contenuto dalla cache (molto veloce!)

L'header Age: 120 indica che il contenuto è in cache da 120 secondi.

Passo 3B: Se non in cache, richiede al server

❌ CACHE MISS — Non trovato in cache, richiesta al server

Il proxy modifica gli header:

GET /page.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
X-Forwarded-For: 192.168.1.10          ← Aggiunge il tuo IP reale
Via: 1.1 proxy-server                  ← Indica che la richiesta passa tramite proxy
Connection: keep-alive

↓ Il proxy invia la richiesta a example.com dal proprio IP

Passo 4: Il server di destinazione elabora la richiesta

Il server example.com riceve la richiesta dal proxy e vede:

  • 🌐 IP sorgente: 203.0.113.45 (IP del proxy, non il tuo 192.168.1.10)
  • 📋 X-Forwarded-For: 192.168.1.10 (opzionale, se il proxy è trasparente)
  • 🔗 Via: 1.1 proxy-server (informazioni sul proxy)
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345
Cache-Control: max-age=3600
Last-Modified: Wed, 13 Jan 2025 10:00:00 GMT

<html>...contenuto della pagina...</html>

Passo 5: Il proxy elabora la risposta

Il proxy riceve la risposta ed esegue le azioni:

  • 💾 Caching: Salva il contenuto nella cache per 3600 secondi (1 ora), secondo Cache-Control
  • 🗜️ Compressione: Può comprimere il contenuto in gzip/brotli per risparmiare traffico
  • 🔍 Filtraggio: Controlla il contenuto per virus, blocca la pubblicità
  • 📊 Logging: Registra nel log: chi, quando, cosa ha richiesto, dimensione della risposta

Passo 6: Il proxy restituisce la risposta al client

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 12345
X-Cache: MISS from proxy-server        ← Richiesta al server
X-Cache-Lookup: MISS from proxy-server
Via: 1.1 proxy-server

<html>...contenuto della pagina...</html>

↑ Il client riceve il contenuto

⚡ Prestazioni: con cache vs senza cache

Fase Senza cache Con cache
DNS lookup 50ms 0ms
Connessione TCP 100ms 0ms
TLS handshake 200ms 0ms
Elaborazione richiesta 150ms 0ms
Trasferimento dati 300ms 50ms
TOTALE 800ms 50ms (16x più veloce!)

🏗️ Architettura del server proxy

Un moderno server proxy è un sistema complesso con diversi componenti che lavorano insieme per garantire prestazioni, sicurezza e affidabilità.

Componenti principali dell'architettura

1️⃣ Connection Manager (Gestore connessioni)

Funzioni:

  • Accetta connessioni TCP in entrata dai client
  • Gestisce il pool di connessioni ai server di destinazione (connection pooling)
  • Riutilizza le connessioni (HTTP Keep-Alive) per risparmiare risorse
  • Gestisce timeout e interruzioni di connessione

Tecnologie: Architettura event-driven (epoll, kqueue), I/O asincrono

2️⃣ Request Parser (Analizzatore di richieste)

Funzioni:

  • Analizza le richieste HTTP (metodo, URL, header, corpo)
  • Valida la correttezza della richiesta
  • Estrae i parametri di autenticazione
  • Determina il tipo di richiesta (GET, POST, CONNECT, ecc.)

3️⃣ Authentication & Authorization (Autenticazione e Autorizzazione)

Metodi di autenticazione:

  • Basic Auth: Login:password in base64 (non sicuro senza HTTPS)
  • IP Whitelist: Accesso solo da indirizzi IP specifici
  • Token Auth: Token di accesso (JWT, OAuth)
  • Certificate Auth: Certificati SSL client

4️⃣ Cache Engine (Motore di caching)

Funzioni:

  • Salva copie delle risorse in memoria/disco
  • Verifica l'attualità della cache (Cache-Control, ETag, Last-Modified)
  • Utilizza algoritmi di sostituzione (LRU, LFU) quando lo spazio è esaurito
  • Supporta richieste condizionali (If-Modified-Since, If-None-Match)

Archiviazioni: Memcached, Redis, Varnish, implementazioni proprietarie

5️⃣ Upstream Handler (Gestore server upstream)

Funzioni:

  • Seleziona il server di destinazione dalla lista (bilanciamento del carico)
  • Stabilisce la connessione con il server upstream
  • Inoltra la richiesta con gli header modificati
  • Gestisce errori e logica di retry

6️⃣ Response Processor (Elaboratore di risposte)

Funzioni:

  • Modifica gli header di risposta
  • Comprime il contenuto (gzip, brotli)
  • Filtra/blocca contenuti indesiderati
  • Aggiunge header di caching e sicurezza

7️⃣ Logging & Monitoring (Registrazione e monitoraggio)

Cosa viene registrato:

  • Timestamp, IP del client, URL richiesto
  • Codice di risposta, dimensione dei dati trasferiti
  • Tempo di elaborazione della richiesta
  • Statistiche di cache hit/miss
  • Errori e anomalie

↔️ Forward vs Reverse Proxy

Esistono due tipi principali di server proxy che svolgono ruoli opposti: il Forward Proxy protegge i client, il Reverse Proxy protegge i server.

➡️ Forward Proxy

Clienti → Forward Proxy → Internet

Client1 ┐
Client2 ├─→ Forward → Server1
Client3 ┘    Proxy     Server2
                        Server3

Caratteristiche:

  • Chi usa: Clienti (utenti)
  • Scopo: Nascondere i client dai server
  • Posizione: Lato client
  • Chi conosce il proxy: I client

Esempi di utilizzo:

  • ✅ Bypass di blocchi e censure
  • ✅ Anonimato su Internet
  • ✅ Filtro dei contenuti aziendali
  • ✅ Web scraping con rotazione IP
  • ✅ Bypass di restrizioni geografiche

Soluzioni popolari:

Squid, ProxyCove, Residential Proxies, proxy SOCKS5

⬅️ Reverse Proxy

Internet → Reverse Proxy → Server

Client1     Reverse  ┌─→ Backend1
Client2  ──→ Proxy  ─┼─→ Backend2
Client3          └─→ Backend3

Caratteristiche:

  • Chi usa: Proprietari di server
  • Scopo: Proteggere e ottimizzare i server
  • Posizione: Lato server
  • Chi conosce il proxy: Gli amministratori

Esempi di utilizzo:

  • ✅ Bilanciamento del carico
  • ✅ Terminazione SSL/TLS
  • ✅ Caching di contenuti statici
  • ✅ Protezione DDoS
  • ✅ Nascondere i server reali

Soluzioni popolari:

Nginx, HAProxy, Cloudflare, AWS ELB, Varnish

🔍 Tabella comparativa

Parametro Forward Proxy Reverse Proxy
Protegge Clienti Server
Visibilità Clienti conoscono il proxy Clienti non lo conoscono
IP visto dal server IP del proxy IP del client (tramite X-Forwarded-For)
Configurazione Sul client Sul server
Caching Per accelerare i client Per scaricare i server
Applicazione tipica Anonimato, bypass blocchi Load balancing, sicurezza

👁️ Transparent vs Explicit Proxy

I server proxy sono classificati anche in base al fatto che il client sia a conoscenza dell'esistenza del proxy: Transparent (trasparente) ed Explicit (esplicito).

👻 Transparent Proxy

Come funziona:

Il proxy intercetta il traffico a livello di rete (tramite router o firewall) senza configurazione del client. Il client pensa di connettersi direttamente al server, ma il traffico passa attraverso il proxy.

Il client pensa:
GET example.com → Direttamente

In realtà:
GET example.com → [Proxy Trasparente] → example.com

Il client non è a conoscenza del proxy!

Caratteristiche:

  • ✅ Non richiede configurazione sul client
  • ✅ Funziona per tutte le applicazioni automaticamente
  • ⚠️ Utilizza metodi GET/POST standard
  • ⚠️ Il client non invia Proxy-Authorization
  • ❌ Più difficile da usare con HTTPS (MITM)

Applicazioni:

  • Reti aziendali (filtraggio senza configurazione)
  • Proxy ISP (caching dei contenuti da parte del provider)
  • Wi-Fi pubblico con filtro contenuti
  • Controllo parentale

📢 Explicit Proxy

Come funziona:

Il client è esplicitamente configurato per utilizzare il proxy. Tutte le richieste vengono inviate al server proxy, che poi le inoltra ai server di destinazione.

Il browser è configurato per il proxy:
Proxy: proxy.example.com:8080

Richiesta HTTP:
GET http://example.com/ HTTP/1.1
Host: example.com
Proxy-Authorization: Basic xyz123

Richiesta HTTPS:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic xyz123

Caratteristiche:

  • ✅ Il client è consapevole del proxy
  • ✅ Supporta l'autenticazione
  • ✅ Utilizza il metodo CONNECT per HTTPS
  • ✅ Controllo completo a livello di applicazione
  • ⚠️ Richiede la configurazione di ogni applicazione

Applicazioni:

  • Anonimato personale (ProxyCove)
  • Web scraping e parsing
  • Test con diversi IP
  • Gestione di più account

🔑 Differenza chiave: Metodo CONNECT

Il proxy Transparent non riceve richieste CONNECT per HTTPS, poiché il browser pensa di connettersi direttamente. Utilizza metodi GET/POST normali.

Il proxy Explicit riceve richieste CONNECT per HTTPS, consentendo di stabilire un tunnel senza decifrare il traffico (la crittografia end-to-end viene mantenuta).

Proxy professionali per qualsiasi attività

Ora capisci come funzionano i proxy: è il momento di metterli in pratica!
ProxyCove è un'infrastruttura moderna con proxy in 195+ paesi.
Registrazione con codice promozionale ARTHELLO = +$1.3 di bonus all'avvio

📖 Continuazione nella Parte 2: Dettagli tecnici — protocolli (HTTP, SOCKS), header, metodo CONNECT, handshake SSL/TLS tramite proxy e funzionamento con HTTPS.

Come funziona un server proxy — Parte 2

Dettagli tecnici: protocolli HTTP e SOCKS, header, metodo CONNECT, handshake SSL/TLS tramite proxy e peculiarità del funzionamento con HTTPS.

Aggiornato: Gennaio 2025 | Tempo di lettura: 17 minuti | Livello: Avanzato

🔌 Protocolli dei server proxy

I server proxy utilizzano vari protocolli per comunicare con i client. Ogni protocollo ha le sue caratteristiche, vantaggi e limitazioni.

Protocolli principali

1. HTTP Proxy

  • Livello OSI: Applicativo (Layer 7)
  • Cosa proxy: Solo traffico HTTP/HTTPS
  • Protocolli: HTTP/1.1, HTTP/2, HTTP/3
  • Caratteristiche: Comprende gli header HTTP, può modificare le richieste
  • Utilizzo: Browser, client API, web scraper

2. HTTPS Proxy (HTTP CONNECT)

  • Livello OSI: Applicativo (Layer 7)
  • Cosa proxy: HTTPS tramite tunneling
  • Metodo: HTTP CONNECT per creare un tunnel
  • Caratteristiche: Non vede il contenuto HTTPS (crittografia end-to-end)
  • Utilizzo: Proxy sicuro per siti HTTPS

3. SOCKS4 Proxy

  • Livello OSI: Sessione (Layer 5)
  • Cosa proxy: Solo connessioni TCP
  • Caratteristiche: Protocollo semplice, non supporta UDP e autenticazione
  • Utilizzo: Obsoleto, raramente usato nel 2025

4. SOCKS5 Proxy

  • Livello OSI: Sessione (Layer 5)
  • Cosa proxy: Traffico TCP e UDP (qualsiasi protocollo)
  • Caratteristiche: Supporta autenticazione, UDP, IPv6
  • Utilizzo: Torrent, giochi, VoIP, proxy universale

📊 Confronto tra protocolli

Caratteristica HTTP HTTPS SOCKS4 SOCKS5
Traffico HTTP
Traffico HTTPS
FTP, SMTP, POP3
Traffico UDP
Autenticazione
Velocità Alta Alta Molto alta Molto alta
Caching

🌐 HTTP Proxy in dettaglio

L'HTTP proxy opera a livello applicativo e comprende la struttura del protocollo HTTP, permettendogli di analizzare e modificare le richieste.

Richiesta tramite HTTP Proxy

Richiesta HTTP normale (senza proxy)

GET /api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Connection: keep-alive

→ Inviata direttamente a api.example.com

Richiesta tramite HTTP Proxy

GET http://api.example.com/api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
Proxy-Connection: keep-alive

→ Inviata al server proxy (non a api.example.com!)

Differenze:

  • L'URL nella prima riga è completo (con protocollo e dominio)
  • Aggiunto l'header Proxy-Authorization
  • Utilizzato Proxy-Connection invece di Connection

Cosa fa il proxy con la richiesta

1. Il proxy riceve la richiesta dal client
2. Verifica Proxy-Authorization (login:password)
3. Estrae l'URL di destinazione: http://api.example.com/api/users
4. Modifica la richiesta per l'invio al server:

GET /api/users HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
X-Forwarded-For: 192.168.1.100        ← Aggiunge l'IP del client
Via: 1.1 proxy-server.com              ← Informazioni sul proxy
X-Real-IP: 192.168.1.100               ← IP reale del client
Connection: keep-alive

5. Invia la richiesta modificata a api.example.com
6. Riceve la risposta da api.example.com
7. Inoltra la risposta al client

🔐 Autenticazione in HTTP Proxy

Basic Authentication

Login e password sono codificati in base64 e trasmessi nell'header:

Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==

Decodificato come: user:password

⚠️ ATTENZIONE: Base64 NON è crittografia!
Usare solo con proxy HTTPS!

Digest Authentication

Un metodo più sicuro che utilizza l'hashing:

1. Client → Proxy: GET http://example.com/ HTTP/1.1
2. Proxy → Client: 407 Proxy Authentication Required
   Proxy-Authenticate: Digest realm="proxy", nonce="abc123"
3. Il client calcola l'hash:
   hash = MD5(username:realm:password)
   response = MD5(hash:nonce:MD5(method:uri))
4. Client → Proxy:
   Proxy-Authorization: Digest username="user",
                                 response="xyz789",
                                 nonce="abc123"

🔒 Metodo HTTP CONNECT

CONNECT è un metodo HTTP speciale che trasforma il proxy in un tunnel TCP. Ciò consente di proxyare HTTPS senza decifrare il traffico.

Come funziona CONNECT

Passo 1: Il client richiede un tunnel

CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
User-Agent: Mozilla/5.0

→ Il client chiede al proxy di stabilire una connessione TCP a example.com:443

Importante: CONNECT viene utilizzato per la porta 443 (HTTPS), non 80 (HTTP).

Passo 2: Il proxy stabilisce la connessione

Il proxy esegue le azioni:
1. Verifica Proxy-Authorization
2. Stabilisce una connessione TCP a example.com:443
3. Risponde al client:

HTTP/1.1 200 Connection established

→ Tunnel stabilito! Ora il proxy inoltra semplicemente i byte.

Passo 3: Il client inizia il TLS handshake

Client → Proxy → Server: ClientHello (inizio TLS)
   [Versione: TLS 1.3]
   [Cipher Suites: TLS_AES_128_GCM_SHA256, ...]
   [SNI: example.com]  ← DPI può vederlo!
   [Supported Groups: x25519, secp256r1]

Server → Proxy → Client: ServerHello
   [Cipher scelto: TLS_AES_128_GCM_SHA256]
   [Certificato Server per example.com]
   [Key Share]

Client → Proxy → Server: ClientKeyExchange
   [Scambio chiave client - crittografato]
   [Change Cipher Spec]

Server → Proxy → Client: Server Finished
   [Server Finished - crittografato]

9. SESSIONE CRITTOGRAFATA STABILITA
   CLIENT ⇄ PROXY ⇄ SERVER: [tutti i dati successivi sono crittografati]

   GET /api/secret HTTP/1.1
   Host: example.com
   Authorization: Bearer secret_token_12345

   ↑ Il proxy NON vede questa richiesta! Solo byte crittografati.

Passo 4: Scambio di dati crittografati

Client → Proxy → Server: [dati crittografati]
Server → Proxy → Client: [dati crittografati]

Il proxy vede solo:
- Volume di dati trasferiti
- Tempo di trasferimento
- Indirizzo IP di destinazione

Il proxy NON vede:
- URL della richiesta
- Header HTTP
- Contenuto della pagina
- Cookie e password

📊 HTTP vs CONNECT — cosa vede il proxy

Informazione HTTP (porta 80) CONNECT (porta 443)
Dominio ✅ Vede ✅ Vede
Percorso URL ✅ Vede completamente ❌ Non vede
Header HTTP ✅ Vede tutti ❌ Non vede
Contenuto pagina ✅ Vede tutto l'HTML ❌ Crittografato
Password e cookie ✅ Vede (PERICOLOSO!) ❌ Crittografato
Volume traffico ✅ Vede ✅ Vede

⚠️ Importante per la sicurezza!

NON USARE MAI un proxy HTTP normale per inserire password!
Il proxy vede tutto in chiaro. Usa sempre siti HTTPS tramite il metodo CONNECT o provider proxy fidati.

🧦 Protocollo SOCKS

SOCKS (Socket Secure) è un protocollo che opera a un livello inferiore rispetto a HTTP e può proxyare qualsiasi traffico TCP/UDP.

Handshake SOCKS5

Fase 1: Scelta del metodo di autenticazione

Client → Server:
┌─────┬─────┬──────────────────┐
│0x05 │0x02 │0x00 0x02         │
└─────┴─────┴──────────────────┘
  VER  NMETHODS  METODI

0x05 = Versione SOCKS 5
0x02 = 2 metodi di autenticazione proposti
0x00 = Nessuna autenticazione
0x02 = Username/Password

Server → Client:
┌─────┬────────┐
│0x05 │0x02    │
└─────┴────────┘
  VER   METODO

0x02 = Metodo Username/Password selezionato

Fase 2: Autenticazione (se richiesta)

Client → Server:
┌─────┬──────┬──────────┬──────┬──────────┐
│0x01 │ ULEN │ USERNAME │ PLEN │ PASSWORD │
└─────┴──────┴──────────┴──────┴──────────┘

0x01 = Versione subnegotiation
ULEN = Lunghezza username
USERNAME = Login
PLEN = Lunghezza password
PASSWORD = Password

Server → Client:
┌─────┬────────┐
│0x01 │0x00    │
└─────┴────────┘
  VER   STATUS

0x00 = Autenticazione riuscita

Fase 3: Richiesta di connessione

Client → Server:
┌─────┬─────┬─────┬──────┬──────────┬──────┐
│0x05 │CMD  │0x00 │ATYP  │DST.ADDR  │PORT  │
└─────┴─────┴─────┴──────┴──────────┴──────┘

0x05 = SOCKS5
CMD:
  0x01 = CONNECT (connessione TCP)
  0x02 = BIND (attesa connessione in entrata)
  0x03 = UDP ASSOCIATE (inoltro UDP)
0x00 = Riservato
ATYP:
  0x01 = Indirizzo IPv4 (4 byte)
  0x03 = Nome di dominio (variabile)
  0x04 = Indirizzo IPv6 (16 byte)

Esempio per example.com:443
0x05 0x01 0x00 0x03 0x0B example.com 0x01BB

Server → Client:
┌─────┬─────┬─────┬──────┬──────────┬──────┐
│0x05 │0x00 │0x00 │0x01  │0.0.0.0   │0x0000│
└─────┴─────┴─────┴──────┴──────────┴──────┘

0x00 = Connessione stabilita con successo

Fase 4: Trasferimento dati

Dopo aver stabilito la connessione, il proxy SOCKS funziona come un tunnel TCP:

Client → SOCKS → Server: [dati dell'applicazione]
Server → SOCKS → Client: [dati dell'applicazione]

SOCKS inoltra semplicemente i byte senza analizzare il contenuto!

Vantaggi di SOCKS5

  • Universalità: Funziona con qualsiasi protocollo (HTTP, FTP, SMTP, BitTorrent, giochi)
  • Supporto UDP: L'unico protocollo proxy con supporto UDP completo
  • Prestazioni: Basso overhead, molto veloce
  • Sicurezza: Non analizza il traffico, trasparente per le applicazioni
  • IPv6: Supporto nativo per indirizzi IPv6

🔐 Handshake SSL/TLS tramite proxy

Capire come TLS funziona tramite un proxy è fondamentale per la sicurezza. Nel 2025, TLS 1.3 è lo standard.

Processo completo HTTPS tramite proxy

1. CLIENTE → PROXY: TCP Handshake
   SYN → SYN-ACK → ACK (connessione stabilita con il proxy)

2. CLIENTE → PROXY: HTTP CONNECT
   CONNECT example.com:443 HTTP/1.1
   Host: example.com:443
   Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
   User-Agent: Mozilla/5.0

3. PROXY → SERVER: TCP Handshake
   (il proxy stabilisce la connessione a example.com:443)

4. PROXY → CLIENTE: 200 Connection established

5. CLIENTE → PROXY → SERVER: TLS ClientHello
   [Versione: TLS 1.3]
   [Cipher Suites: TLS_AES_128_GCM_SHA256, ...]
   [SNI: example.com]  ← DPI può vederlo!
   [Supported Groups: x25519, secp256r1]

6. SERVER → PROXY → CLIENTE: TLS ServerHello
   [Cipher scelto: TLS_AES_128_GCM_SHA256]
   [Certificato Server per example.com]
   [Key Share]

7. CLIENTE → PROXY → SERVER: TLS Finished
   [Scambio chiave client - crittografato]
   [Change Cipher Spec]

8. SERVER → PROXY → CLIENTE: TLS Finished
   [Server Finished - crittografato]

9. SESSIONE CRITTOGRAFATA STABILITA
   CLIENTE ⇄ PROXY ⇄ SERVER: [tutti i dati successivi sono crittografati]

   GET /api/secret HTTP/1.1
   Host: example.com
   Authorization: Bearer secret_token_12345

   ↑ Il proxy NON vede questo contenuto! Solo byte crittografati.

⚠️ Cosa possono vedere i sistemi DPI

Anche attraverso un tunnel CONNECT, i sistemi DPI (Deep Packet Inspection) possono estrarre alcune informazioni:

  • 📌 SNI (Server Name Indication): Il nome di dominio nel ClientHello (trasmesso in chiaro in TLS 1.2 e precedenti)
  • 📌 Indirizzo IP di destinazione: Dove sta andando la connessione
  • 📌 Volume di traffico: Quanti dati vengono trasferiti
  • 📌 Timing patterns: I modelli di attività possono rivelare il tipo di contenuto

🛡️ Protezione: ECH (Encrypted Client Hello)

Nel 2025, i server moderni supportano ECH (Encrypted Client Hello), uno standard di TLS 1.3 che crittografa l'SNI. Questo rende impossibile determinare il dominio tramite DPI.

🔓 SSL Interception (Proxy MITM)

Alcuni proxy aziendali eseguono SSL Interception, ovvero decifrano il traffico HTTPS:

CLIENTE → [TLS al proxy] → PROXY → [TLS al server] → SERVER

Il proxy esegue due handshake TLS:
1. Con il client (usando un proprio certificato)
2. Con il server (per conto del client)

Il proxy vede TUTTO il contenuto HTTPS!

⚠️ Richiede l'installazione del certificato root del proxy sul client
⚠️ Il browser mostrerà un avviso se il certificato non è attendibile

Applicazioni: Reti aziendali per il controllo dei dipendenti, antivirus per la scansione HTTPS, sistemi DLP.

📋 Header HTTP importanti per il proxy

X-Forwarded-For

Contiene l'indirizzo IP reale del client. Aggiunto dal proxy.

X-Forwarded-For: 192.168.1.100

X-Real-IP

Alternativa a X-Forwarded-For, contiene un singolo IP.

X-Real-IP: 192.168.1.100

Via

Mostra la catena di proxy attraverso cui è passata la richiesta.

Via: 1.1 proxy1, 1.1 proxy2

X-Forwarded-Proto

Indica il protocollo della richiesta originale (http/https).

X-Forwarded-Proto: https

X-Forwarded-Host

L'header Host originale inviato dal client.

X-Forwarded-Host: example.com

Proxy-Authorization

Credenziali per l'autenticazione sul server proxy.

Proxy-Authorization: Basic xyz123

🔍 Come il server identifica un proxy

Il server può rilevare che una richiesta proviene da un proxy dai seguenti indicatori:

  • Presenza degli header X-Forwarded-* e Via
  • Indirizzo IP presente in un database noto di server proxy
  • Incongruenza tra geolocalizzazione IP e altri parametri (lingua, timezone)
  • Modelli di attività anomali (richieste troppo veloci)

Proxy affidabili con supporto per tutti i protocolli

Ora conosci i dettagli tecnici del funzionamento dei proxy: applica questa conoscenza con ProxyCove!
HTTP, HTTPS, SOCKS5 — tutti i protocolli sono supportati. 195+ paesi.
Registrazione con codice promozionale ARTHELLO = +$1.3 di bonus all'avvio

📖 Continuazione nella Parte Finale: Caching, bilanciamento del carico, esempi pratici, scelta del proxy e conclusioni.

Come funziona un server proxy — Finale

Caching, bilanciamento del carico, esempi pratici, scelta del proxy per diverse attività e conclusioni. Tutto ciò che devi sapere sui proxy nel 2025.

Aggiornato: Gennaio 2025 | Tempo di lettura: 16 minuti | Livello: Medio - Avanzato

💾 Meccanismi di caching nel proxy

Il caching è una delle funzioni chiave dei server proxy, che consente di accelerare il caricamento dei contenuti del 50-90% e ridurre il carico sui server backend.

Come funziona il caching

Algoritmo decisionale sul caching

1. Arriva una richiesta al proxy
   GET /images/logo.png

2. Il proxy calcola la chiave di cache:
   key = hash(metodo + URL + header)
   key = "GET:example.com:/images/logo.png"

3. Verifica della cache:
   if (cache esiste AND cache è attuale):
       ✅ CACHE HIT
       - Controlla Cache-Control: max-age
       - Controlla l'header Expires
       - Se attuale → restituisci dalla cache
       - Se scaduto → richiesta condizionale (If-Modified-Since)
   else:
       ❌ CACHE MISS
       - Richiedi al server di origine
       - Salva in cache (se cacheable)
       - Restituisci al client

4. Determina se è possibile memorizzare nella cache:
   ✅ Sì, se:
      - Metodo HTTP: GET o HEAD
      - Stato: 200, 301, 304, 404
      - Cache-Control: public, max-age > 0
      - NON ci sono header: Set-Cookie, Authorization
   ❌ No, se:
      - Cache-Control: no-store, private
      - Pragma: no-cache
      - Richieste POST, PUT, DELETE
      - Contenuto dinamico con Set-Cookie

Header di caching

Header Valore Azione del proxy
Cache-Control: max-age=3600 Memorizza nella cache per 1 ora ✅ Memorizza
Cache-Control: no-cache Verifica sempre con il server ⚠️ Richiesta condizionale
Cache-Control: no-store Non memorizzare mai ❌ Non memorizza
Cache-Control: public Può essere memorizzato pubblicamente ✅ Memorizza
Cache-Control: private Solo per un singolo client ❌ Non memorizza
ETag: "abc123" Identificatore di versione ✅ Per la validazione
Last-Modified: date Data di modifica ✅ Per la validazione

Richieste condizionali

Quando la cache è scaduta, il proxy può verificare l'attualità utilizzando richieste condizionali:

Scenario 1: Verifica tramite ETag
────────────────────────────────────
Proxy → Server:
GET /image.jpg HTTP/1.1
If-None-Match: "abc123"

Se il file NON è cambiato:
Server → Proxy:
HTTP/1.1 304 Not Modified
ETag: "abc123"

→ Il proxy serve dalla cache (risparmio di traffico!)

Se il file è cambiato:
Server → Proxy:
HTTP/1.1 200 OK
ETag: "xyz789"
[nuovo contenuto]

→ Il proxy aggiorna la cache


Scenario 2: Verifica tramite data
────────────────────────────────────
Proxy → Server:
GET /style.css HTTP/1.1
If-Modified-Since: Wed, 13 Jan 2025 10:00:00 GMT

Server → Proxy:
HTTP/1.1 304 Not Modified

→ La cache è attuale, la serviamo dalla cache

Algoritmi di sostituzione della cache

Quando la cache è piena, il proxy deve decidere cosa eliminare:

1. LRU (Least Recently Used)

Elimina gli oggetti a cui non si è acceduto di recente. L'algoritmo più popolare.

image1.jpg (ultimo accesso: 2 minuti fa)
style.css (ultimo accesso: 10 minuti fa) ← Eliminato per primo
logo.png (ultimo accesso: 1 minuto fa)

2. LFU (Least Frequently Used)

Elimina gli oggetti richiesti meno frequentemente.

logo.png (richieste: 1000)
style.css (richieste: 50) ← Eliminato per primo
image1.jpg (richieste: 500)

3. FIFO (First In First Out)

Elimina gli oggetti più vecchi nella cache. Semplice ma non sempre efficace.

4. Algoritmi sensibili alla dimensione

Considerano la dimensione degli oggetti. Ad esempio, eliminano file grandi richiesti raramente per fare spazio a molti file piccoli popolari.

📊 Efficienza del caching

Statistiche tipiche della cache di un proxy web:

  • 📈 Hit Rate: 60-80% per contenuti statici (immagini, CSS, JS)
  • 📉 Hit Rate: 5-20% per contenuti dinamici (API, HTML)
  • Accelerazione: Cache hit gestito in 10-50ms contro 200-800ms per cache miss
  • 💾 Risparmio traffico: 40-70% di riduzione del traffico in uscita verso l'origine
  • 🔋 Riduzione carico: 50-90% di riduzione delle richieste ai server backend

⚖️ Bilanciamento del carico

Il Reverse Proxy viene spesso utilizzato per distribuire il carico tra più server backend, garantendo alta disponibilità e scalabilità.

Algoritmi di bilanciamento del carico

1️⃣ Round Robin (Circolare)

Le richieste vengono distribuite in sequenza tra i server.

Richiesta 1 → Server A
Richiesta 2 → Server B
Richiesta 3 → Server C
Richiesta 4 → Server A (il ciclo si ripete)

✅ Vantaggi: Semplicità, distribuzione uniforme
❌ Svantaggi: Non tiene conto del carico dei server

2️⃣ Least Connections (Minimo numero di connessioni)

La nuova richiesta viene inviata al server con il minor numero di connessioni attive.

Server A: 5 connessioni
Server B: 2 connessioni ← Nuovo richiesta qui
Server C: 8 connessioni

✅ Vantaggi: Tiene conto del carico attuale
✅ Ideale per connessioni a lunga durata (WebSocket, streaming)

3️⃣ IP Hash

Il server viene selezionato in base all'hash dell'indirizzo IP del client. Un client finisce sempre sullo stesso server.

hash(192.168.1.100) % 3 = 1 → Server B
hash(192.168.1.200) % 3 = 0 → Server A
hash(192.168.1.150) % 3 = 2 → Server C

✅ Vantaggi: Session persistence senza sticky sessions
❌ Svantaggi: Distribuzione non uniforme con pochi client

4️⃣ Weighted Round Robin (Pesato)

Ai server vengono assegnati pesi in base alla loro potenza.

Server A (peso: 5) → riceve 5 richieste
Server B (peso: 2) → riceve 2 richieste
Server C (peso: 3) → riceve 3 richieste

Totale 10 richieste distribuite in proporzione 5:2:3

✅ Ideale per server eterogenei (potenza diversa)

5️⃣ Least Response Time

Seleziona il server con il tempo di risposta più basso e il minor numero di connessioni.

Server A: 50ms, 10 connessioni
Server B: 30ms, 5 connessioni ← Selezionato
Server C: 100ms, 3 connessioni

✅ Prestazioni ottimali per i client
⚠️ Richiede monitoraggio health checks

🏥 Health Checks (Verifiche di salute)

Il Load Balancer controlla costantemente la disponibilità dei server backend:

Active Health Checks

Il proxy invia attivamente richieste di verifica:

Ogni 5 secondi:
GET /health HTTP/1.1
Host: backend-server

Risposta 200 OK → Server sano ✅
Risposta 5xx o timeout → Server non disponibile ❌

Passive Health Checks

Analisi delle richieste reali dei client:

Se negli ultimi 10 richieste:
- 5 hanno restituito errori 5xx
- 3 sono terminate con timeout
→ Segna il server come unhealthy per 30 secondi

💼 Esempi pratici di utilizzo

🕷️

Web Scraping

Obiettivo: Effettuare il parsing di 100.000 pagine senza essere bannati.

Soluzione:

  • Proxy residenziali rotanti
  • Nuovo IP ogni 10 richieste
  • SOCKS5 per universalità
  • Rate limiting: 2 req/sec per IP

Risultato: 0% di blocchi, 95% di richieste riuscite

🎯

Verifica Annunci

Obiettivo: Verificare la visualizzazione di annunci in 50 paesi.

Soluzione:

  • Proxy Geo-targeting (per paese)
  • IP residenziali per realismo
  • Screenshot tramite browser headless
  • Rotazione degli header User-Agent

Risultato: Verifica accurata del posizionamento annunci

💰

Monitoraggio Prezzi

Obiettivo: Monitorare i prezzi dei concorrenti 24/7.

Soluzione:

  • Proxy Data Center (più economici)
  • Richieste pianificate ogni 2 ore
  • Utilizzo di più provider proxy
  • Fallback su residenziali in caso di blocco

Risultato: Intelligence sui prezzi in tempo reale

🎮

Sneaker Botting

Obiettivo: Acquistare scarpe in edizione limitata (drop).

Soluzione:

  • Proxy residenziali (per bypassare anti-bot)
  • Proxy ISP per il checkout (stabilità)
  • 1 account = 1 proxy
  • Bassa latenza (<50ms)

Risultato: Checkout riuscito prima del sold out

📱

Gestione Social Media

Obiettivo: Gestire oltre 100 account Instagram.

Soluzione:

  • Proxy Mobile (IP 4G/5G)
  • Sticky sessions (10-30 minuti)
  • 1 account = 1 proxy (per il fingerprinting)
  • Geo-match: account e proxy dalla stessa nazione

Risultato: 0 ban, engagement naturale

🌐

SEO Rank Tracking

Obiettivo: Tracciare le posizioni in Google per regione.

Soluzione:

  • Proxy con geolocalizzazione (città/regione)
  • Residenziali per l'accuratezza dei risultati
  • Bassa frequenza di richiesta (1-2/min)
  • Parsing SERP con anti-captcha

Risultato: Posizioni locali accurate

🎯 Scelta del tipo di proxy per la tua attività

Attività Tipo di proxy Protocollo Costo
Web Scraping Residenziale HTTP/SOCKS5 $2.7/GB
Social Media (Instagram, TikTok) Mobile 4G/5G HTTP/SOCKS5 $3.8/GB
Monitoraggio Prezzi (siti semplici) Data Center HTTP $1.5/GB
Sneaker Bots Residenziale + ISP HTTP $2.7/GB
Contenuti Geo-restricted (Netflix) Residenziale HTTPS/SOCKS5 $2.7/GB
SEO Rank Tracking Residenziale HTTP $2.7/GB
Verifica Annunci Residenziale HTTP $2.7/GB
Test API (sviluppo) Data Center HTTP/SOCKS5 $1.5/GB

⚡ Ottimizzazione delle prestazioni del proxy

Migliori pratiche 2025

✅ Connection Pooling

Riutilizzare le connessioni TCP al proxy. HTTP Keep-Alive risparmia 100-200ms per ogni richiesta.

✅ Supporto HTTP/2

Utilizzare HTTP/2 per il multiplexing di più richieste su una singola connessione.

✅ Geo-vicinanza

Scegliere proxy geograficamente vicini al server di destinazione. Latenza = distanza.

✅ DNS Caching

Memorizzare nella cache le richieste DNS sul client. La ricerca DNS richiede 20-50ms.

✅ Retry Logic

Retry automatico in caso di errori 5xx con exponential backoff e cambio proxy.

✅ Session Persistence

Per attività con sessioni, utilizzare sticky sessions (un IP per tutta la sessione).

⚠️ Cosa evitare

  • ❌ Usare proxy gratuiti (lenti, insicuri, instabili)
  • ❌ Rate limit troppo alti (si ottengono captcha e blocchi)
  • ❌ Un solo proxy per tutte le richieste (fingerprinting, blocco IP)
  • ❌ Ignorare gli header retry-after (rate limiting dal server)
  • ❌ Usare proxy HTTP per dati sensibili

🎓 Conclusioni

Il server proxy è uno strumento potente che nel 2025 è diventato parte integrante dell'internet moderno. Capire come funziona ti dà un vantaggio competitivo in molti settori.

🔑 Punti chiave

1. Architettura

Il proxy è un intermediario intelligente che non si limita a inoltrare dati, ma li elabora, li memorizza nella cache e li ottimizza.

2. Protocolli

HTTP per il traffico web, SOCKS5 per l'universalità, CONNECT per HTTPS: ogni protocollo per il suo compito.

3. Sicurezza

TLS 1.3 con ECH protegge dal DPI. Il metodo CONNECT mantiene la crittografia end-to-end. Usa HTTPS ovunque.

4. Prestazioni

Il caching accelera il caricamento del 50-90%. Il bilanciamento del carico distribuisce il traffico per alta disponibilità.

5. Scelta del tipo

Residenziali per bypassare, Mobili per i social, Data Center per compiti semplici. La scelta giusta = successo del progetto.

6. Trend moderni

HTTP/3, QUIC, ECH (Encrypted Client Hello), routing basato su AI — i proxy evolvono con internet.

🚀 Prossimi passi

  1. Pratica: Configura un proxy nel tuo progetto e testa diversi protocolli
  2. Monitoraggio: Tieni traccia delle metriche (hit rate, latenza, error rate)
  3. Ottimizzazione: Sperimenta con le impostazioni di caching e balancing
  4. Sicurezza: Controlla regolarmente i log per anomalie
  5. Scalabilità: Aggiungi server proxy all'aumentare del carico

💡 Ricorda: Il proxy non è magia, ma uno strumento ingegneristico. Capirne il funzionamento ti permette di usarlo in modo efficace, evitando errori e raggiungendo le massime prestazioni. Nel 2025, un proxy configurato correttamente è un vantaggio competitivo.

Pronto ad applicare le tue conoscenze?

Ora sei un esperto di server proxy! Applica le tue conoscenze con ProxyCove.
195+ paesi, tutti i protocolli, qualità premium, 99.9% di uptime.
Registrazione con codice promozionale ARTHELLO = +$1.3 di bonus all'avvio

Tariffe ProxyCove 2025:

✅ HTTP, HTTPS, SOCKS5 | ✅ API + Dashboard | ✅ Supporto 24/7 | ✅ Attivazione istantanea

📚 Guida completa sui server proxy terminata!

Hai studiato:
Parte 1: Basi di funzionamento, architettura, forward vs reverse, transparent vs explicit
Parte 2: Protocolli HTTP/SOCKS, metodo CONNECT, handshake SSL/TLS, header
Parte 3: Caching, bilanciamento del carico, esempi pratici, ottimizzazione

🎉 Congratulazioni! Ora comprendi come funzionano i server proxy nel 2025.