Proxy per n8n: configurazione della richiesta HTTP senza 403 (2026)

```html

Hai creato un workflow in n8n, ha funzionato per due settimane e poi ha iniziato a cadere costantemente con 403 Forbidden. La prima idea è stata "il sito è rotto" o "le credenziali sono scadute". Nella maggior parte dei casi, il problema è un altro: il server di destinazione ha riconosciuto che la richiesta è arrivata non da un browser, ma da un'automazione che utilizza l'IP del data center del tuo VPS. n8n ha un meccanismo di proxy integrato, ma è semplicemente disattivato per impostazione predefinita e alcune impostazioni si trovano in posti inaspettati.

Analizziamo passo dopo passo: dove viene impostato il proxy in n8n, quali sono le differenze tra self-hosted e Cloud, e quali tre trappole consumano più tempo.

Perché n8n viene bloccato più spesso del tuo browser

n8n è la più grande piattaforma di automazione open-source: quasi 198.000 stelle e 59.600 fork su GitHub, la versione attuale al momento della pubblicazione è [email protected] (24 luglio 2026). La popolarità ha un rovescio della medaglia: i sistemi anti-bot conoscono bene il suo fingerprint di rete.

Tre fattori si combinano:

User-Agent ti identifica immediatamente. Non è un'ipotesi, ma un comportamento ufficialmente documentato. In n8n esiste una variabile N8N_ENFORCE_GLOBAL_USER_AGENT (per impostazione predefinita false), e la documentazione descrive chiaramente il suo scopo: sostituire la stringa User-Agent "nuda" n8n con una compatibile con RFC Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/), per prevenire il blocco delle richieste da parte dei firewall delle applicazioni web. Il problema è arrivato a segnalazioni di bug: nell'issue #28280 (aperta il 10 aprile 2026, chiusa) è descritto come i nodi nativi restituissero bare-UA n8n, e i siti rispondessero con 403 per "Bad User-Agent". La stessa node HTTP Request utilizza axios sotto il cofano e senza un'intestazione manuale è facilmente riconoscibile.
L'IP del tuo server è di data center. n8n vive quasi sempre su VPS o nel cloud. Questi intervalli sono pubblicamente noti e contrassegnati come "non utente": alcune piattaforme li bloccano più severamente, fino a limiti di richieste significativamente più bassi rispetto alle connessioni domestiche.
Il ritmo delle richieste è disumano. Un nodo in ciclo emette decine di richieste al secondo da un unico indirizzo: questo è il classico trigger per il rate-limit e il successivo ban dell'IP.

Passo 1. Proxy nel nodo stesso (funziona anche su Cloud)

Il modo più veloce è impostare un proxy specifico per una singola richiesta HTTP:

Apri il nodo HTTP Request.
In basso clicca su Add Option e seleziona Proxy — questo è un campo di testo per l'URL del server proxy.
Inserisci la stringa nel formato standard con autorizzazione: http://LOGIN:PASSWORD@host:port.
Qui aggiungi anche l'opzione intestazioni: attiva Send Headers e imposta User-Agent di un browser reale — copia manualmente la stringa attuale da DevTools del tuo Chrome.

Questo metodo è l'unico disponibile su n8n Cloud: lì non gestisci l'ambiente di esecuzione, quindi le variabili di ambiente di sistema non sono accessibili, e l'IP in uscita non è fissato e cambia da esecuzione a esecuzione. Il vantaggio di questo approccio è la granularità: diversi nodi di un unico workflow possono passare attraverso proxy diversi e diverse geolocalizzazioni. Lo svantaggio è che se ci sono venti nodi, dovrai modificarne venti.

Passo 2. Proxy globale tramite variabili di ambiente (self-hosted)

Sul tuo server, è più logico incapsulare tutto il traffico in uscita contemporaneamente. n8n legge le variabili standard:

HTTP_PROXY — URL del proxy per il traffico HTTP non crittografato dei nodi;
HTTPS_PROXY — lo stesso per le richieste TLS/SSL (nella pratica è il tuo parametro principale);
ALL_PROXY — utilizzato quando non sono impostati proxy più specifici HTTP_PROXY/HTTPS_PROXY;
NO_PROXY — elenco di host separati da virgole, ai quali n8n andrà direttamente bypassando il proxy.

In docker-compose.yml appare così:

HTTPS_PROXY=http://LOGIN:[email protected]:8080
NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.com
N8N_ENFORCE_GLOBAL_USER_AGENT=true

Assicurati di compilare NO_PROXY. Altrimenti, attraverso il proxy esterno andranno anche le richieste interne — al tuo Postgres, ai contenitori vicini, al tuo dominio webhook. Il sintomo è "tutto è rotto dopo aver attivato il proxy", anche se i siti di destinazione sono diventati accessibili.

Se desideri non rivelare la versione di n8n all'esterno, invece della stringa RFC, imposta la tua tramite N8N_GLOBAL_USER_AGENT_VALUE — essa sovrascrive il valore predefinito. La logica generale per configurare il traffico del contenitore è la stessa di altri scenari: l'analisi dei formati e delle insidie è disponibile nella guida su proxy per contenitori Docker.

Passo 3. Tre trappole che rubano la serata

Trappola 1: la registrazione delle variabili conta

Questo non è ovvio e quasi non si trova nei tutorial. n8n gestisce le variabili che terminano con _PROXY tramite il pacchetto npm proxy-from-env, e questo impone il proprio ordine di priorità: le versioni minuscole (http_proxy) hanno priorità su quelle maiuscole (HTTP_PROXY), se entrambe sono impostate. Uno scenario classico di dolore: un https_proxy dimenticato giace nel sistema da tempo, tu scrivi accuratamente HTTPS_PROXY nel compose — e il traffico continua a seguire il vecchio indirizzo. Controlla entrambi i registri.

Un dettaglio separato per Enterprise: la variabile proxy per le richieste al server di licenza https_proxy_license_server deve essere solo in minuscolo, formato — https://user:pass@proxy:port.

Trappola 2: il nodo Code non fa ciò che hai in mente

Un consiglio comune dai forum è "scrivi nel nodo Code la tua richiesta tramite axios con un agente proxy". Per impostazione predefinita, questo non funzionerà: n8n disabilita l'importazione dei moduli nel nodo Code. Devi abilitarli esplicitamente — NODE_FUNCTION_ALLOW_BUILTIN per quelli integrati e NODE_FUNCTION_ALLOW_EXTERNAL per quelli esterni (da n8n/node_modules). Un ulteriore dettaglio: se hai task runners in modalità esterna, queste variabili sono impostate non nell'ambiente del contenitore, ma nella configurazione dei runner /etc/n8n-task-runners.json come env-override. È più semplice e sicuro rimanere sull'opzione Proxy standard nel nodo.

Trappola 3: il proxy è attivo, ma il ritmo è lo stesso

Il proxy cambia l'indirizzo, ma non il comportamento. Se il workflow continua a emettere una raffica di richieste, brucerai semplicemente nuovi IP. Nello stesso nodo ci sono freni integrati:

Batching — Items per Batch (quanti elementi in un pacchetto) e Batch Interval in millisecondi (0 = senza pausa). Imposta un pacchetto di 1–5 e un intervallo di 1000–3000 ms.
Timeout — in millisecondi; i canali residenziali sono più lenti di quelli dei data center, il valore predefinito deve essere aumentato.
Response → Never Error — non interrompe l'intero workflow al primo 403, permette di gestire il codice di risposta tramite ramificazione.
Pagination — modalità Update a Parameter e Response Contains Next URL invece di cicli fatti in casa.

A livello di istanza, il ritmo è limitato da N8N_CONCURRENCY_PRODUCTION_LIMIT (per impostazione predefinita -1, quindi senza limiti) — un valore ragionevole proteggerà sia il pool di proxy che il server stesso. Maggiori informazioni su come le piattaforme conteggiano le tue richieste e cosa fare con i limiti sono disponibili nell'analisi per bypassare il rate limiting tramite proxy.

Quali proxy scegliere per n8n

La scelta non dipende dalla "prestigiosità", ma da chi si trova dall'altra parte.

Data center. Economici e veloci. Adatti per API ufficiali, servizi interni, siti amichevoli con i bot e qualsiasi compito in cui è necessario semplicemente un indirizzo statico stabile — ad esempio, per far inserire il tuo IP nella whitelist di un partner. Su piattaforme protette restituiscono esattamente lo stesso 403 che un VPS nudo: i loro intervalli sono noti. Questa è la base per compiti batch senza anti-bot.
Residenziali. Indirizzi di veri provider domestici — ciò di cui hai bisogno per raccogliere dati da piattaforme con una protezione seria, per contenuti geo-dipendenti e monitoraggio dei prezzi. Per workflow che navigano su siti pubblici, i proxy residenziali sono il default funzionante: prendi la rotazione su richiesta per il parsing massivo e sessioni sticky, quando è necessario mantenere una sessione su una catena di nodi.
Mobile. Il livello di fiducia più alto: dietro un operatore ci sono migliaia di abbonati reali, bannare un IP del genere è costoso per la piattaforma. Giustificati dove ci sono i blocchi più severi — lavoro con social media e messaggistica. Per questo paghi in velocità e prezzo.

Uno schema pratico su un workflow misto: API ufficiali — direttamente o tramite data center, siti pubblici — tramite residenziali, social media — tramite mobili. L'opzione Proxy è configurabile su ciascun nodo separatamente, quindi combinare tutto questo in uno scenario è possibile senza soluzioni di fortuna.

Checklist prima del lancio

Il proxy è impostato — o come opzione Proxy nel nodo, o tramite HTTPS_PROXY; su Cloud è disponibile solo la prima opzione.
Entrambi i registri delle variabili sono stati controllati — le minuscole sovrascrivono le maiuscole.
NO_PROXY chiude localhost, il database e gli host interni.
User-Agent è stato sostituito: N8N_ENFORCE_GLOBAL_USER_AGENT=true o un'intestazione personalizzata nel nodo. Controlla anche la coerenza delle altre intestazioni — un insieme incoerente di headers rivela l'automazione non meno del User-Agent stesso.
Batching è attivato con un intervallo non nullo.
È stato effettuato un test su 3–5 elementi, e non su tutta la lista.

Conclusione

Il 403 in n8n è quasi sempre il risultato di più di una causa, ma la somma di tre: un User-Agent riconoscibile, un IP di data center e un ritmo di richieste troppo uniforme. Anche la soluzione richiede un insieme di azioni, non solo un flag: sostituire l'UA, deviare il traffico attraverso il proxy giusto e rallentare il nodo tramite Batching. Tutti e tre i meccanismi sono già integrati nella piattaforma — basta trovarli e attivarli.

Iniziare è più semplice con un canale residenziale sui nodi più problematici e un data center sugli altri: il pagamento a ProxyCove avviene in base al traffico, quindi per i test puoi prendere un volume minimo e vedere come si comporta il tuo specifico workflow. Scegliere un proxy per il compito e inserire la stringa nel campo Proxy è questione di pochi minuti.