Résolution des noms d’hôte SOCKS5 dans le client HTTP de Go

Dans le transport HTTP standard de Go 1.27.3, socks5 et socks5h traitent les noms de destination de la même façon. Une destination indiquée par un nom d’hôte est transmise au proxy comme nom d’hôte. Changer ces schémas ne bascule pas entre DNS local et distant comme dans curl.

package main

import (
    "fmt"
    "log"
    "net/http"
    "net/url"
    "time"
)

func main() {
    proxyURL, err := url.Parse("socks5://203.0.113.10:1080")
    if err != nil {
        log.Fatal(err)
    }

    transport := http.DefaultTransport.(*http.Transport).Clone()
    transport.Proxy = http.ProxyURL(proxyURL)
    defer transport.CloseIdleConnections()

    client := &http.Client{
        Transport: transport,
        Timeout: 15 * time.Second,
    }
    response, err := client.Get("https://example.com/")
    if err != nil {
        log.Fatal(err)
    }
    defer response.Body.Close()
    fmt.Println(response.StatusCode)
}

Remplacez l’adresse de documentation par votre point d’accès SOCKS5 ; vous pouvez chercher des candidats dans la liste de proxys SOCKS5. L’exemple utilise le transport propre à net/http ; une autre bibliothèque Go peut avoir un comportement différent.

Il reste deux noms à distinguer. Une adresse numérique de proxy n’exige pas de recherche du nom du proxy ; un proxy désigné par un nom doit être trouvé localement avant l’envoi d’une requête SOCKS. Une destination numérique n’a pas de nom à résoudre et ne peut pas démontrer le traitement des noms d’hôte. Pour examiner le choix SOCKS réel, vérifiez si le champ de destination contient un nom ou une adresse.

Le transport standard prend en charge les schémas de proxy http, https, socks5 et socks5h. Une étiquette générique SOCKS ne prouve pas qu’un point d’accès accepte SOCKS5. Cet exemple transmet HTTP sur TCP et ne teste ni les autres commandes SOCKS ni le relais UDP.