127.0.0.1:57573 Guida e risoluzione dei problemi della porta Localhost

Esegui un piccolo script Flask. Incolla `http://127.0.0.1:57573` nel browser. Due possibili risultati: la pagina si carica, oppure il terminale si illumina di rosso con la scritta `ECONNREFUSED` e il browser mostra la triste icona della spina scollegata.

Nessuno dei due esiti è misterioso. L'indirizzo è composto da due parti: 127.0.0.1 è l'indirizzo di loopback IPv4 e 57573 è una porta che il sistema operativo ha assegnato quasi a caso dal suo pool di porte ad alto numero. Questa guida svela entrambi i misteri. Analizzeremo perché così tanti server locali finiscono per utilizzare una porta di questo tipo e esamineremo i sei problemi che possono verificarsi prima che la connessione venga stabilita. Al termine, dovreste essere in grado di associare un servizio all'interfaccia corretta, vedere cosa è effettivamente in ascolto su una porta, risolvere i conflitti di porte e i blocchi del firewall e proteggere il server locale prima di renderlo accessibile da Internet.

Cosa significa 127.0.0.1:57573 in parole semplici

Tre parti. L'indirizzo IP 127.0.0.1 è l'indirizzo di loopback IPv4. I due punti indicano "e su questa porta". 57573 è la porta stessa, che si trova nell'intervallo di numeri elevati che nessun servizio ampiamente diffuso possiede in modo permanente.

Collegandosi ad esso, il kernel instrada il pacchetto direttamente al computer locale. Nessuna scheda di rete. Nessuno switch. Nessun viaggio di andata e ritorno attraverso alcun cavo. L'indirizzo permette a un processo di comunicare con altri processi sullo stesso host senza esporre nulla a una rete esterna. Questo è il principio fondamentale dell'interfaccia di loopback.

La prenotazione è più vecchia della maggior parte degli sviluppatori che la utilizzano. La RFC 1122, sezione 3.2.1.3, ha bloccato per sempre l'intero blocco 127.0.0.0/8, tutti i 16.777.216 indirizzi, già nel 1989. Il registro degli indirizzi IPv4 per scopi speciali dell'IANA, regolato dalla RFC 6890 e aggiornato dalla RFC 8190, contrassegna lo stesso blocco come non inoltrabile, non instradabile a livello globale e riservato dal protocollo. Qualsiasi processo in ascolto su 127.0.0.1 vede solo il traffico proveniente dal proprio host. Qualsiasi pacchetto in arrivo dall'esterno che dichiari un indirizzo sorgente 127 viene silenziosamente scartato. Gli esperti di rete chiamano questi pacchetti "marziani".

Localhost, questo il nome, è semplicemente un nome host più comprensibile per lo stesso concetto. Apri il file `/etc/hosts` su macOS o Linux, oppure `C:\Windows\System32\drivers\etc\hosts` su Windows, e vedrai questa riga quasi all'inizio: `127.0.0.1 localhost`.

Indirizzo di loopback: come localhost instrada il traffico verso la tua macchina

127.0.0.1 è l'indirizzo più famoso. Non è l'unico. L'intero blocco 127.0.0.0/8, con oltre sedici milioni di indirizzi, è collegato tramite loop. È possibile effettuare un ping a 127.42.42.42 su Linux e funziona. La maggior parte di noi usa 127.0.0.1 per abitudine, ma l'intero blocco è importante quando si leggono le regole di iptables o si verifica un'immagine protetta. (Da anni circola nell'IETF una bozza che propone di riutilizzare la maggior parte del blocco 127/8 per il traffico unicast, ma non è stata adottata.)

Il lato IPv6 è più snello. Un solo indirizzo, `::1`, definito nella RFC 4291. Nessun /8. Nessun indirizzo di riserva. Se il tuo servizio si associa solo a `::1`, qualsiasi tentativo di connessione a 127.0.0.1 non andrà a buon fine, e viceversa. Su un moderno sistema Linux e su macOS, `localhost` si risolve in entrambi gli indirizzi, quindi il browser di solito tenta prima `::1`, fallisce e poi ripiega su un altro indirizzo. Questo si manifesta come un piccolo ma percettibile ritardo. Bloccando un indirizzo specifico all'interno dello script, l'ambiguità scompare.

Il kernel gestisce i pacchetti di loopback su un'interfaccia virtuale. Linux la chiama `lo`, macOS `lo0`. I comandi `ip link show` e `ifconfig lo0` la mostrano. Lo stesso firewall che controlla tutto il resto controlla anche il loopback, motivo per cui una configurazione firewall aggressiva può bloccare il traffico locale. Approfondiremo questo aspetto nelle sezioni successive.

In sintesi, per lo sviluppo: 127.0.0.1 è l'interfaccia più sicura a cui connettersi. Nessun elemento esterno al computer può raggiungerla. I container e le macchine virtuali hanno un proprio loopback, separato da quello dell'host, ed è proprio questo che spesso confonde gli sviluppatori la prima volta che si aspettano che 127.0.0.1 all'interno di un container Docker raggiunga magicamente un servizio sul laptop.

Perché la porta 57573? Spiegazione degli intervalli di numerazione delle porte IANA.

La porta 57573 non è speciale. Il sistema operativo o il framework l'hanno assegnata perché era libera. Per capire perché un numero così grande compare così spesso, bisogna esaminare come IANA suddivide lo spazio delle porte a 16 bit. L'intero schema è descritto nella RFC 6335 e nel Registro dei nomi dei servizi e dei numeri di porta del protocollo di trasporto di IANA.

L'intervallo raccomandato da IANA per le porte effimere è 49152–65535. I kernel reali, tuttavia, spesso non sono d'accordo. Linux, di default, utilizza l'intervallo 32768–60999 (`sysctl net.ipv4.ip_local_port_range`). Windows, a partire da Vista, utilizza l'intervallo 49152–65535. L'era di XP utilizzava l'intervallo 1025–5000, un intervallo ristretto che consumava rapidamente le porte sotto carico e causava famosi disservizi. macOS si attiene alle specifiche IANA. La porta 57573 rientra in tutti gli intervalli predefiniti moderni. Questo singolo fatto spiega in gran parte perché compare nei log degli sviluppatori.

Quando il tuo codice esegue `app.run(port=0)` in Flask o `server.listen(0)` in Node, il sistema operativo sceglie una porta libera qualsiasi dal suo intervallo dinamico locale. Su un laptop Linux questo significa un intervallo compreso tra 32768 e 60999. La porta 57573 è comodamente disponibile. Lo stesso vale per gli strumenti di assegnazione automatica: Vite (che nel 2022 ha deliberatamente impostato come predefinito 127.0.0.1 per impedire agli sviluppatori di far trapelare server tramite Wi-Fi nei bar), webpack-dev-server, VS Code Live Server, Jupyter, i driver bridge di Selenium, Playwright, il debugger `--inspect=0` di Node. Tutti questi strumenti chiedono semplicemente al kernel una porta alta libera e utilizzano quella che viene loro assegnata.

Quindi, se la porta 57573 compare in una traccia dello stack, la risposta più ovvia è quasi sempre quella giusta. O qualche processo si è connesso a quella porta di proposito, oppure un framework ha richiesto "una porta libera qualsiasi" e il kernel ha scelto questa. Non c'è niente di sbagliato nella porta 57573 in particolare. La maggior parte dei framework di test e sviluppo locali considera l'intero intervallo di porte alte come un ambiente sicuro e isolato, perché nessun servizio pubblico dipende da esso.

Associazione di un server a 127.0.0.1 vs 0.0.0.0 vs ::1

Scegliendo il target di binding sbagliato si possono ottenere strani bug. Tre definizioni da tenere a mente.

L'indirizzo 127.0.0.1 si associa esclusivamente all'interfaccia di loopback IPv4. È raggiungibile dalla stessa macchina su qualsiasi client IPv4. Mai dall'esterno.

::1 associa solo l'interfaccia di loopback IPv6. Stessa idea, ma solo per i client IPv6 presenti sulla stessa macchina.

L'indirizzo 0.0.0.0 associa tutte le interfacce IPv4 del dispositivo. Chiunque si connetta al tuo computer può raggiungerlo, inclusi i telefoni sulla stessa rete Wi-Fi, i dispositivi VPN e (tramite port forwarding) la rete internet pubblica.

Per lo sviluppo quotidiano, usa 127.0.0.1 come interfaccia. È l'unica interfaccia in cui firewall, policy VPN ed esposizioni accidentali smettono di essere un problema. Flask, FastAPI ed Express la utilizzano tutte di default.

Nella mia esperienza, le persone tendono a utilizzare 0.0.0.0 per tre motivi diversi: testando su un telefono tramite LAN, testando all'interno di Docker o seguendo un tutorial il cui autore ha copiato e incollato l'indirizzo IP predefinito sbagliato. Ognuno di questi casi offre una soluzione più sicura. Per i test in LAN, è consigliabile associare l'indirizzo IP alla LAN specifica e aggiungere una regola temporanea al firewall. Per Docker, è possibile associare 0.0.0.0 all'interno del container, ma pubblicarlo sull'host con `docker run -p 127.0.0.1:8080:8080 …`. Per i tutorial, è meglio ignorare la riga relativa a 0.0.0.0 e impostare 127.0.0.1 come indirizzo predefinito, a meno che non si abbia un valido motivo.

Un semplice frammento di codice Flask mostra l'impostazione predefinita sicura:

```

from flask import Flask

app = Flask(__name__)

@app.route("/")

def index():

restituisci "Ciao, localhost!"

se __name__ == "__main__":

app.run(host="127.0.0.1", port=57573)

```

Ispezione della porta 57573 con netstat, lsof e ss

Qualcosa è in ascolto sulla porta 57573 e non hai idea di cosa sia. Il comando dipende dal tuo sistema operativo. Memorizza questo breve elenco e lo userai per anni.

Output tipico di Linux:

```

$ ss -tlnp | grep 57573

ASCOLTA 0 4096 127.0.0.1:57573 0.0.0.0:* utenti:(("python3",pid=18432,fd=4))

```

Sei campi, da sinistra a destra. Stato. Coda di invio. Coda di ricezione. Indirizzo locale. Indirizzo peer. Il processo. PID 18432 in questo caso. `kill 18432` su Unix. `Stop-Process -Id 18432` in PowerShell. Fatto. Se tutto ciò che volevi era ripristinare la porta, questa è la soluzione completa.

E se non compare nulla? Significa che non c'è nessun server in ascolto, il che di per sé è un'informazione utile. L'errore del browser che continui a visualizzare, "Connessione rifiutata", di solito significa proprio questo: il tuo server non è raggiungibile. Si è bloccato all'avvio oppure non è mai riuscito a connettersi all'indirizzo che hai digitato.

Errori comuni di connessione e il loro significato

Sei cose. Questo è l'intero elenco di errori che vedi all'indirizzo 127.0.0.1:57573. Leggi la stringa di errore, scegli un bucket.

`EADDRINUSE`, "Indirizzo già in uso" o "La porta 57573 è già allocata" significano tutti la stessa cosa: un'altra applicazione sta utilizzando la porta. I comandi di ispezione della sezione precedente ti indicano quale. Termina il processo o usa semplicemente una porta diversa per il tuo servizio. Strumenti come netstat o lsof risolvono il problema con una sola riga di comando.

`ECONNREFUSED`, la stringa più amichevole "Connessione rifiutata", significa: TCP è riuscito ad entrare nel kernel, ma nessuno ha risposto. Il tuo server si è bloccato all'avvio o non è mai stato collegato. Controlla il terminale da cui lo hai avviato. Il traceback è proprio lì.

I messaggi `ETIMEDOUT` e "Connection timed out" indicano che i pacchetti vengono persi silenziosamente. Su 127.0.0.1, questo non dovrebbe mai accadere. Se si verifica, la causa è una regola del firewall, un agente VPN o uno strumento di protezione degli endpoint. Disabilitateli uno alla volta, riprovate e ripetete il processo.

Il messaggio `EACCES` ("Permesso negato") viene visualizzato quando si tenta di eseguire il binding su una porta inferiore a 1024 senza i privilegi di root. Utilizzare una porta più alta, come la 57573, oppure eseguire il binario come root. La terza opzione non esiste.

Gli errori `EAI_NONAME` e altri errori DNS indicano che il nome host non è mai stato risolto. Il file hosts dovrebbe mappare `localhost` a 127.0.0.1. Un client VPN potrebbe averlo sovrascritto. Un amministratore di sistema potrebbe aver distribuito un'immagine danneggiata. Apri il file hosts. Verifica che `127.0.0.1 localhost` sia la prima riga non commentata.

Ultimo, quello più insidioso. Dopo uno spegnimento pulito, il kernel blocca il socket in TIME_WAIT per circa due minuti. Riavviando rapidamente il server, compare il messaggio "Indirizzo già in uso" anche se nessuno è in ascolto. Tre soluzioni: aspettare, impostare `SO_REUSEADDR` nel file di configurazione del server, oppure passare a una porta diversa. La maggior parte di noi opta per la seconda soluzione.

Leggi la stringa di errore. Seleziona il bucket. Applica la correzione. L'intero ciclo si chiude solitamente in meno di un minuto.

Impostazioni del firewall che bloccano la porta 57573

In teoria, il traffico di loopback è sempre consentito. In pratica, le regole del firewall a volte lo impediscono. I soliti sospetti nel 2026:

• Il firewall delle applicazioni di macOS con l'opzione "Blocca connessioni in entrata" impostata su rigorosa. Aggiungi il file binario proprietario della porta 57573 all'elenco delle connessioni consentite in Impostazioni di sistema → Rete → Firewall.
• Si è verificato un problema di incompatibilità del profilo del firewall di Windows Defender. Un nuovo strumento di sviluppo ti chiede di autorizzare l'accesso. D'istinto, fai clic su Annulla. Il sistema blocca l'accesso senza alcun messaggio di errore. Apri `wf.msc`, rimuovi la regola di negazione e accetta la richiesta la volta successiva.
• Linux ufw o iptables con policy predefinite più restrittive. `ufw status verbose` elenca le regole. `ufw allow from 127.0.0.1` apre esplicitamente il loopback. La maggior parte delle distribuzioni con impostazioni predefinite consente già `lo`, ma alcune immagini con restrizioni di sicurezza non lo permettono.
• Un agente VPN aziendale o zero-trust intercetta il traffico. Alcuni agenti fungono da proxy per le connessioni locali tramite un listener in userspace e alterano silenziosamente il loopback. Disabilita l'agente per un minuto per confermare.
• Antivirus o protezione degli endpoint. I prodotti EDR a volte bloccano i file binari di sviluppo che si collegano a porte elevate finché non vengono inseriti nella whitelist.

In qualsiasi ambiente aziendale gestito, è probabile che si verifichi almeno uno di questi problemi. La procedura diagnostica è sempre la stessa: controlla le impostazioni del firewall, quindi esegui `curl http://127.0.0.1:57573` dalla stessa shell che ha avviato il server. Curl funziona ma il browser non risponde? Stai utilizzando l'interfaccia sbagliata (spesso `::1` invece di 127.0.0.1) oppure è attiva una policy di accesso alla rete privata (PNA). Anche Curl non funziona? Il kernel o il firewall intercettano il pacchetto prima che raggiunga il tuo codice. Gli sviluppatori web e gli amministratori di rete si scambiano questi suggerimenti su wiki interni perché i sintomi sembrano identici finché non si verificano due volte.

Localhost in Docker, WSL e GitHub Codespaces

Tre situazioni in cui localhost smette di comportarsi come previsto.

Prima di tutto Docker. All'interno di un container, 127.0.0.1 è l'indirizzo di loopback del container stesso , non il tuo. Quindi, se il tuo laptop esegue un servizio su 127.0.0.1:57573, il container non può raggiungerlo tramite quello stesso indirizzo. Mai. Il gateway dell'host si trova altrove: `host.docker.internal` su Mac e Windows, oppure un indirizzo IP di bridge su Linux. La direzione inversa (servizio del container, chiamante dall'host) richiede un flag di pubblicazione. `docker run -p 127.0.0.1:57573:57573 my-image`. Eliminando `-p`, la porta semplicemente non esiste al di fuori del container.

WSL2 ha una sua personalità. La modalità di rete mirror (attivabile su Windows 11 22H2 e versioni successive, tramite `[wsl2] networkingMode=mirrored`) condivide lo stack di rete dell'host con la macchina virtuale WSL. In questa modalità, un servizio su 127.0.0.1:57573 all'interno di WSL risponde su Windows allo stesso indirizzo. La modalità NAT predefinita inoltra comunque le porte, ma solo per le stringhe `localhost`, non sempre per l'indirizzo 127.0.0.1. Esiste anche un bug noto e fastidioso, tracciato come Microsoft WSL #40169. La modalità mirror blocca silenziosamente ampie porzioni di porte ad alto numero di porte. I tentativi di associazione su 127.0.0.1 falliscono quindi con `WinError 10013`, che Python segnala utilmente come `PermissionError`. Quando una porta non si associa su Windows senza un motivo apparente, controllare prima questo.

GitHub Codespaces e VS Code Remote SSH funzionano in direzione opposta. Inoltrano automaticamente le porte. Avvia un server all'interno di un Codespace su 127.0.0.1:57573 e l'editor apre un tunnel per te, esponendo quella porta a un URL univoco github.dev. La scheda del browser che apri sul tuo laptop comunica con quell'URL, non con 127.0.0.1, e la richiesta passa attraverso il tunnel tornando all'area di lavoro.

Quindi il nome dell'endpoint sembra lo stesso. Il percorso effettivo seguito dal pacchetto è però completamente diverso in ogni ambiente. Cinque minuti spesi a capire in quale ambiente ci si trova permettono di risparmiare venti minuti passati a fissare un messaggio di "connessione rifiutata".

HTTPS su Localhost: le migliori pratiche per uno sviluppo locale sicuro

I browser moderni e molte API richiedono l'utilizzo di HTTPS anche per lo sviluppo locale. Service worker, geolocalizzazione, l'API degli appunti, qualsiasi cookie contrassegnato come "sicuro": tutti questi elementi si rifiutano di funzionare tramite HTTP. C'è un'eccezione: 127.0.0.1, che il browser considera già come un contesto sicuro. Questa eccezione riguarda la maggior parte degli sviluppatori occasionali. Per tutto il resto, è necessario utilizzare TLS in locale.

Lo strumento più pulito in assoluto è mkcert, scritto da Filippo Valsorda. Eseguilo una volta con `mkcert -install`, poi con `mkcert localhost 127.0.0.1 ::1` e otterrai un certificato `localhost+2.pem` e una chiave. Configura il tuo server di sviluppo in modo che utilizzi questa coppia di certificati. Il browser mostrerà un lucchetto senza alcun avviso, perché mkcert ha installato una CA radice locale nel tuo sistema e Firefox la memorizza nell'archivio delle CA attendibili. Let's Encrypt non può emettere un certificato valido per `127.0.0.1`, poiché non esiste un dominio da convalidare, quindi una CA locale è la soluzione standard.

Ecco altri schemi che vale la pena conoscere:

• Per i test automatizzati, punta a un servizio magic-DNS (`nip.io`, `sslip.io`, `traefik.me`, `localhost.direct`) per trasformare un indirizzo IP in un nome host reale come `127.0.0.1.nip.io`. Let's Encrypt o ZeroSSL possono certificare questi indirizzi, e `localhost.direct` pubblica persino un certificato wildcard pre-emesso.
• Associa il tuo servizio a 127.0.0.1, non a 0.0.0.0, in modo che il certificato (che copre `127.0.0.1`) corrisponda effettivamente.
• Non includere i certificati di sviluppo in Git. Per impostazione predefinita, mkcert li inserisce nella directory di lavoro. Aggiungi immediatamente la coppia di certificati al file `.gitignore`.
• Ruota l'autorità di certificazione locale ogni pochi mesi. Il comando `mkcert -uninstall` la rimuove completamente.
• Se ti trovi dietro un proxy MITM aziendale, accetta che il proxy scambierà i tuoi certificati. Disabilita il proxy su `127.0.0.1` se i tuoi strumenti lo supportano.

Anche i browser hanno una regola speciale che vale la pena conoscere. Secondo la specifica W3C Secure Contexts, `http://127.0.0.1`, `http://localhost` e `http://[::1]` sono considerati "potenzialmente affidabili", il che consente a una pagina HTTPS di accedervi senza attivare un blocco per contenuti misti. Questa eccezione è prevista specificamente per lo sviluppo locale.

Localhost non rappresenta un confine di sicurezza nel modo in cui gli sviluppatori spesso credono. I browser possono essere ingannati e indotti a raggiungerlo da siti web arbitrari tramite il DNS rebinding, in cui un sito malevolo risolve nuovamente il proprio nome host in 127.0.0.1 e consente al codice JavaScript presente sulla pagina dell'attaccante di comunicare con i servizi locali sotto l'origine del sito originale. La vulnerabilità CVE di Zoom del 2019 (CVE-2019-13450) ne è un esempio emblematico. Zoom installava un server web nascosto su `localhost:19421` su macOS, in modo che i link per le riunioni potessero avviare l'applicazione desktop e qualsiasi sito web potesse accedervi per forzare l'accesso dell'utente a una riunione con la videocamera accesa. Circa 4 milioni di Mac sono stati interessati, oltre a tredici client white-label distribuiti con lo stesso motore. Chrome 142, rilasciato alla fine del 2025, ha sostituito il precedente sistema di accesso alla rete privata (Private Network Access) con l'accesso alla rete locale (Local Network Access). Le pagine pubbliche ora necessitano di un'autorizzazione esplicita prima di poter raggiungere indirizzi di loopback o privati, il che neutralizza la maggior parte delle vulnerabilità automatizzate da Singularity di NCC Group. Un avviso di Straiker del 2025 documentava lo stesso attacco contro i server Model Context Protocol (MCP) in esecuzione localmente, una vulnerabilità che si sta diffondendo rapidamente man mano che gli sviluppatori eseguono un numero maggiore di agenti LLM su loopback. È fondamentale associare le connessioni esclusivamente a 127.0.0.1, richiedere l'autenticazione, controllare l'intestazione `Origin` ed evitare CORS con caratteri jolly sulle API di sviluppo. Queste quattro abitudini consentono di individuare la maggior parte di queste vulnerabilità.

Suggerimenti per la risoluzione dei problemi e una rapida lista di controllo diagnostica

Se l'indirizzo 127.0.0.1:57573 non risponde, controlla questo breve elenco prima di sospettare qualche trucco.

1. Verifica che il server sia effettivamente in esecuzione. Controlla il terminale da cui lo hai avviato. Se si è bloccato, la traccia dello stack si trova proprio lì.

2. Verifica che sia associato a 127.0.0.1, non a 0.0.0.0 o ::1 da solo. La maggior parte dei framework stampa l'indirizzo di binding all'avvio. Leggi la riga.

3. Prova a eseguire `curl -v http://127.0.0.1:57573` dalla stessa shell. Curl funziona? Il problema è nel browser, non nel server.

4. Scopri chi possiede la porta. Linux, `ss -tlnp | grep :57573`. macOS, `lsof -i :57573`. Windows, `netstat -ano | findstr :57573`.

5. Il processo che lo gestisce non è quello giusto? Terminalo, quindi riavvia il server.

6. Nessun segnale in ascolto? Controlla il log di avvio. `EACCES` indica una porta privilegiata. `EADDRINUSE` di solito indica un valore TIME_WAIT obsoleto.

7. Prova la forma IPv6. `curl http://[::1]:57573`. Se uno tra `127.0.0.1` e `::1` funziona e l'altro no, il tuo servizio è single-stack.

8. Prova una porta diversa: passa `--port 12345` (o qualsiasi altra porta) e ricarica. La nuova porta funziona? Hai un conflitto specifico della porta.

9. Disattiva VPN, antivirus e agenti endpoint per un minuto. Se la porta 57573 inizia a rispondere, significa che uno di questi stava consumando tutto il traffico.

10. Riavvia il sistema, o almeno riavvia l'interfaccia di rete. Quasi mai è la soluzione. Elimina i socket obsoleti e lo stato di firewall bloccato quando nient'altro funziona.

Per la maggior parte dei problemi di sviluppo, i primi quattro passaggi di risoluzione dei problemi individuano la causa dell'errore di connessione. I restanti riguardano i casi davvero insoliti, in cui un'incongruenza IPv6, socket obsoleti o un firewall ostile nascondono il vero problema. Leggi il messaggio di errore, quindi segui l'elenco.

Una nota rilevante per Plisio. Quando si integrano i webhook di un processore di pagamenti in criptovalute, il gateway necessita di un URL pubblico a cui inviare richieste POST. Le fatture di Plisio accettano un `callback_url` nel payload dell'API e il sistema invia aggiornamenti di stato a tale endpoint tramite POST. Il server locale all'indirizzo 127.0.0.1:57573 è per definizione irraggiungibile da Internet, quindi la soluzione standard è un tunnel. Nel 2026 le opzioni più comuni sono ngrok (Personal $8/mese, Pro $20/mese), Cloudflare Tunnel (gratuito fino a 50 utenti su Zero Trust) e Tailscale Funnel (gratuito per uso personale, a pagamento per team a partire da $6/utente/mese). Ciascuno di questi richiede un hostname pubblico e inoltra il traffico al server 127.0.0.1:57573 del vostro laptop. Gli SDK di Plisio per Python, PHP e Node includono una funzione di supporto `validate_callback` che verifica l'hash `verify_hash` di HMAC-SHA1 sul corpo JSON ordinato, quindi una volta configurato il tunnel, lo stesso gestore funziona in modo identico sia in ambiente di sviluppo che in produzione.

Mathis Curcio

Mathis Curcio is a senior content strategist and NFT specialist at Plisio. With over 5 years of experience in the Web3 space, Mathis focuses on the evolution of NFT ecosystems, digital collectibles, and decentralized ownership models. He creates accessible, insight-driven content that bridges the gap between blockchain innovation and mainstream adoption. His expertise spans NFT market trends, use cases across art and gaming, and the infrastructure powering next-generation tokenized assets.