ERR_CONNECTION_REFUSED e Solana: rendete i vostri progetti affidabili

Quando il vostro progetto digitale si blocca, il costo è immediato

Un sito che rifiuta le connessioni. Una transazione blockchain che si trascina per 30 secondi. In entrambi i casi, il risultato è identico: perdete denaro, credibilità, o entrambi.

Non è una questione di fortuna. È una questione di padronanza tecnica.

Nel 2026, i progetti digitali performanti si fondano su due pilastri raramente insegnati insieme: l’affidabilità dei fondamentali (risolvere gli errori di base che bloccano tutto) e il dominio delle innovazioni all’avanguardia (sfruttare le capacità delle infrastrutture moderne al massimo potenziale). Ignorare l’uno o l’altro significa costruire sulla sabbia.

In questo articolo copriamo entrambi. Prima come diagnosticare e correggere l’errore ERR_CONNECTION_REFUSED — quello che manda in panico tutti in produzione. Poi come ottimizzare la velocità delle transazioni su Solana per applicazioni decentralizzate realmente competitive.

---

Capire l’errore ERR_CONNECTION_REFUSED prima di correggerlo

L’errore ERR_CONNECTION_REFUSED è uno dei più frequenti nello sviluppo web. Compare nel browser, nei log di Node.js, nelle chiamate API — e ha sempre lo stesso significato: il vostro client cerca di raggiungere un server che non è in ascolto all’indirizzo o alla porta richiesta.

Nessun mistero. Il server non è raggiungibile. O perché è fermo, o perché è in ascolto sulla porta sbagliata, o perché un firewall blocca la connessione.

Quello che vediamo tipicamente nei nostri clienti: nell’80% dei casi, l’errore deriva da una configurazione locale mal allineata — un servizio backend avviato sulla porta 3001 mentre il frontend chiama la porta 3000. Sembra banale. Blocca un’intera giornata di sviluppo se non si sa dove cercare. Una scelta errata di hosting può aggravare questi problemi di disponibilità in produzione.

Diagnosi in 4 fasi

Fase 1 — Verificare che il servizio sia avviato

Prima di tutto, confermate che il server sia in esecuzione:

# Linux / macOS
lsof -i :3000

# Windows (PowerShell)
netstat -ano | findstr :3000

Se il comando non restituisce nulla, il vostro server semplicemente non è avviato. Avviatelo.

Fase 2 — Verificare l’indirizzo di ascolto

Un server può essere in esecuzione ma in ascolto solo su 127.0.0.1 (localhost). Se chiamate da un altro contenitore Docker o da una macchina remota, la connessione sarà rifiutata. Verificate la vostra configurazione:

// Express.js — ascolto su tutte le interfacce
app.listen(3000, '0.0.0.0', () => {
  console.log('Server accessibile su tutte le interfacce');
});

Fase 3 — Verificare le regole del firewall

Su un server Linux in produzione:

# Verificare le regole UFW
sudo ufw status

# Aprire una porta se necessario
sudo ufw allow 3000/tcp

Su un VPS cloud (AWS, OVH, Hetzner), pensate anche ai security groups e alle regole di rete a livello di infrastruttura — indipendentemente dal firewall di sistema.

Fase 4 — Caso Docker: la rete interna

In un ambiente Docker Compose, i servizi comunicano tramite il loro nome di servizio, non tramite localhost. Questa è la fonte numero uno di ERR_CONNECTION_REFUSED in ambienti containerizzati.

# docker-compose.yml
services:
  frontend:
    environment:
      - API_URL=http://backend:3000  # Nome del servizio, non localhost
  backend:
    ports:
      - "3000:3000"

La trappola CORS che maschera il vero problema

Ecco dove la cosa si fa interessante. A volte, l’ERR_CONNECTION_REFUSED è nascosto da un errore CORS nella console del browser. Gli sviluppatori passano ore a configurare gli header CORS mentre il vero problema è a monte: il server non è raggiungibile.

Regola semplice: se avete un errore CORS e un errore di connessione nel pannello Network dei DevTools, correggete prima la connessione. Il CORS viene dopo.

---

Ottimizzare la velocità delle transazioni Solana nel 2026

Passiamo all’altro estremo dello spettro. Solana è oggi una delle blockchain più veloci del mercato — teoricamente 65 000 transazioni al secondo, commissioni quasi nulle. In pratica, se la vostra applicazione non sfrutta correttamente l’infrastruttura, le transazioni si trascineranno, scadranno o falliranno sotto carico.

Ecco cosa fa davvero la differenza nel 2026.

Scegliere l’endpoint RPC giusto — e non fermarsi a quello predefinito

Il RPC (Remote Procedure Call) è il gateway tra la vostra applicazione e la blockchain Solana. L’endpoint pubblico predefinito (api.mainnet-beta.solana.com) è permanentemente sovraccarico. Usare quell’endpoint in produzione equivale a prendere l’autostrada nelle ore di punta senza corsia riservata.

Le alternative che cambiano le cose:

• Helius — probabilmente il miglior rapporto qualità/affidabilità attualmente, con funzionalità di indicizzazione avanzate
• QuickNode — performante, multi-regione, buona documentazione
• Triton One — orientato all’alta performance per le applicazioni critiche
• Alchemy (supporto Solana) — se siete già nel loro ecosistema

import { Connection } from '@solana/web3.js';

// Evitate questo in produzione
const connection = new Connection('https://api.mainnet-beta.solana.com');

// Fate questo invece
const connection = new Connection(
  process.env.SOLANA_RPC_URL, // Il vostro endpoint premium
  {
    commitment: 'confirmed',
    confirmTransactionInitialTimeout: 60000,
  }
);

Configurare la priorità delle commissioni (Priority Fees)

Dall’introduzione dei priority fees su Solana, una transazione senza commissioni di priorità competitive può aspettare diversi secondi — o addirittura scadere — durante i periodi di congestione della rete.

Quello che le agenzie non vi dicono mai: non configurare i priority fees è la prima causa di transazioni lente nel 2026, ben prima dei problemi di infrastruttura. Allo stesso modo, capire gli header HTTP e il loro impatto sulle prestazioni permette di evitare colli di bottiglia lato server.

import {
  ComputeBudgetProgram,
  TransactionMessage,
  VersionedTransaction,
} from '@solana/web3.js';

// Recuperare le commissioni di priorità recenti per calibrare
const recentFees = await connection.getRecentPrioritizationFees();
const averageFee = recentFees.reduce((sum, fee) => 
  sum + fee.prioritizationFee, 0) / recentFees.length;

// Aggiungere il 20% sopra la media per passare in priorità
const priorityFee = Math.ceil(averageFee * 1.2);

const computeBudgetInstruction = ComputeBudgetProgram.setComputeUnitPrice({
  microLamports: priorityFee,
});

Usare le transazioni versionate e le lookup tables

Le versioned transactions (introdotte con il formato V0) combinate con le Address Lookup Tables permettono di ridurre la dimensione delle transazioni e di includerne di più in un unico blocco. Per applicazioni con molte istruzioni, si tratta di un guadagno misurabile.

import {
  AddressLookupTableProgram,
  VersionedTransaction,
  TransactionMessage,
} from '@solana/web3.js';

// Costruire una transazione versionata
const message = new TransactionMessage({
  payerKey: payer.publicKey,
  recentBlockhash: blockhash,
  instructions: [
    computeBudgetInstruction,
    ...leVostreIstruzioni,
  ],
}).compileToV0Message(addressLookupTableAccounts);

const transaction = new VersionedTransaction(message);

Strategia di retry e gestione delle scadenze

Una transazione Solana scade se non viene confermata entro circa 150 blocchi (~60-90 secondi). Senza una strategia di retry, la vostra applicazione lascia silenziosamente transazioni fallite indietro.

La nostra esperienza lo conferma: nei progetti dApp che abbiamo seguito, implementare una logica di retry robusta riduce i fallimenti silenziosi del 70%.

async function sendTransactionWithRetry(
  connection,
  transaction,
  signers,
  maxRetries = 3
) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      // Recuperare un blockhash fresco a ogni tentativo
      const { blockhash, lastValidBlockHeight } = 
        await connection.getLatestBlockhash('confirmed');
      
      transaction.recentBlockhash = blockhash;
      transaction.sign(...signers);
      
      const signature = await connection.sendRawTransaction(
        transaction.serialize(),
        { skipPreflight: false, maxRetries: 0 }
      );
      
      // Attendere la conferma con timeout
      await connection.confirmTransaction({
        signature,
        blockhash,
        lastValidBlockHeight,
      });
      
      return signature;
      
    } catch (error) {
      if (attempt === maxRetries - 1) throw error;
      console.log(`Tentativo ${attempt + 1} fallito, nuovo tentativo...`);
      await new Promise(resolve => setTimeout(resolve, 1000 * (attempt + 1)));
    }
  }
}

---

Cosa hanno in comune questi due argomenti

In superficie, risolvere un ERR_CONNECTION_REFUSED e ottimizzare le transazioni Solana sembrano non avere nulla in comune. In realtà, illustrano lo stesso principio fondamentale.

Le prestazioni tecniche non sono un’opzione. Sono un vincolo di business.

Un sito inaccessibile perde clienti. Una transazione lenta allontana gli utenti da una dApp. In entrambi i casi, la soluzione non è magica — è metodica.

“L’affidabilità non è l’assenza di guasti. È la capacità di anticiparli, rilevarli e correggerli prima che costino caro.”

Quello che osserviamo nei progetti che seguiamo: i team che documentano le proprie configurazioni (porte, endpoint, parametri di rete) perdono 5 volte meno tempo a fare debug rispetto a chi lavora a memoria. Un .env.example aggiornato, un README con i prerequisiti di rete, una sezione “risoluzione dei problemi” nella documentazione interna — ci vogliono 2 ore per scriverla e fa risparmiare giorni in 12 mesi.

---

3 azioni concrete da applicare questa settimana

Ecco cosa potete fare adesso, senza aspettare:

1. Verificate le configurazioni di porte ed endpoint Fate l’inventario di tutti i servizi del vostro stack e verificate che gli indirizzi di ascolto siano esplicitamente documentati. Quante volte avete perso 30 minuti perché una porta era mal configurata in locale?

2. Se sviluppate su Solana, fate un benchmark del vostro RPC attuale Misurate il tempo di risposta medio del vostro endpoint con un semplice script di test. Se superate costantemente i 300 ms di media, cambiate fornitore. I guadagni sono immediati e misurabili.

3. Implementate una strategia di retry su tutte le transazioni Nessun retry = fallimenti silenziosi che non vedrete mai nei log. È il debito tecnico più costoso e più invisibile. Se avete bisogno di uno sguardo esperto sulle vostre configurazioni di rete o server, il nostro servizio di manutenzione e assistenza del sito può intervenire rapidamente.

---

Costruire progetti che reggano

Le prestazioni web nel 2026 non si riassumono nell’avere lo stack più moderno. Si costruiscono su due livelli simultanei: padroneggiare i fondamentali che evitano i guasti di base, e sfruttare le capacità avanzate delle infrastrutture attuali.

In GDM-Pixel, è esattamente l’approccio che applichiamo nei nostri progetti — che si tratti di un sito vetrina per un artigiano o di un’applicazione decentralizzata. L’affidabilità non è negoziabile. Le prestazioni nemmeno.

Avete un progetto web o un’applicazione con problemi di prestazioni o affidabilità? Contattateci per un audit tecnico — guardiamo cosa blocca, vi diciamo cosa si può migliorare, senza vendervi una ristrutturazione completa se non è necessaria.