Resolución de nombres SOCKS5 en el cliente HTTP de Go
Entiende por qué socks5 y socks5h no seleccionan modos DNS distintos en el transporte HTTP estándar de Go.
En el transporte HTTP estándar de Go 1.27.3, socks5 y socks5h tratan igual los nombres de destino. Un destino con nombre de host se envía al proxy como nombre de host. Cambiar esos esquemas no alterna entre DNS local y remoto como ocurre en 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)
}
Sustituye la dirección de documentación por tu punto de acceso SOCKS5; puedes buscar candidatos en la lista de proxies SOCKS5. El ejemplo usa el transporte propio de net/http; otra biblioteca Go puede tener un comportamiento diferente.
Aun así hay que distinguir dos nombres. Una dirección numérica del proxy no necesita resolver su host; un proxy indicado por nombre debe localizarse localmente antes de enviar una solicitud SOCKS. Un destino numérico no tiene nombre que resolver y no demuestra cómo se manejan los nombres de host. Para inspeccionar la selección SOCKS real, comprueba si el campo de destino contiene un nombre o una dirección.
El transporte estándar admite los esquemas de proxy http, https, socks5 y socks5h. Una etiqueta genérica SOCKS no demuestra que el punto de acceso admita SOCKS5. Este ejemplo envía HTTP sobre TCP y no prueba otros comandos SOCKS ni el reenvío UDP.