Un server SOCKS5 può accettare la connessione TCP e rifiutare comunque la richiesta di raggiungere una destinazione. Leggi la risposta nella fase corretta prima di decidere quale endpoint ha fallito.

Prima avviene la selezione del metodo. L’autenticazione con nome utente e password, se scelta, ha un proprio risultato. Solo dopo il server restituisce la risposta a CONNECT o a un altro comando SOCKS. Un valore di byte di una fase non va interpretato con la tabella di un’altra.

Le risposte alle richieste distinguono errori diversi

Valore della rispostaSignificato nella risposta a una richiesta SOCKS5
0x01Errore generale del server.
0x02Connessione non consentita dalle regole.
0x03Rete irraggiungibile.
0x04Host irraggiungibile.
0x05Connessione rifiutata.
0x06TTL scaduto.
0x07Comando non supportato.
0x08Tipo di indirizzo non supportato.

Per esempio, un rifiuto a livello di richiesta viene segnalato dopo aver raggiunto il servizio SOCKS. È diverso dal rifiuto della connessione TCP iniziale a quel servizio da parte del sistema operativo.

Un errore del tipo di indirizzo può riguardare la rappresentazione IPv4, IPv6 o come nome host. Non significa automaticamente che l’intero endpoint non supporti SOCKS5. Analogamente, un comando UDP non supportato non dice nulla di definitivo su una richiesta TCP CONNECT separata.

Raccogliere il contesto che rende utile il codice

Quando scrivi una segnalazione di errore, conserva insieme al risultato indirizzo del proxy, comando, host e porta di destinazione, famiglia di indirizzi e modalità DNS. Se amministri l’endpoint, sono utili i log delle politiche lato server. Un rifiuto delle regole richiede di controllare l’autorizzazione applicabile, non di aumentare il timeout di connessione.

La risposta è il resoconto del server, non una diagnosi indipendente completa della rete di destinazione. Anche le formulazioni dei client variano. Registra fase e risposta sottostante quando disponibili, invece di basarti solo su un breve messaggio di errore tradotto.

Articoli correlati