HTTP ou SOCKS5: que IP de proxy deberías escoller?
Escolle o tipo de proxy segundo a aplicación, o tráfico admitido e a necesidade de DNS no proxy.
Abre primeiro a configuración de proxy da aplicación. Os protocolos admitidos determinan as entradas que podes usar; unha etiqueta impresionante ou un porto coñecido non engaden compatibilidade ao cliente.
| Aplicación ou tarefa | Escolle e comproba |
|---|---|
| Só ofrece un campo de proxy HTTP | Un punto axeitado da lista de proxys HTTP. Proba tamén HTTPS CONNECT se precisas destinos HTTPS. |
| Admite SOCKS5 e necesita opcións de conexión ou DNS | Un punto SOCKS5 coas opcións necesarias admitidas nos dous extremos. |
| Necesita UDP | Verifica UDP no cliente e no punto final; a etiqueta SOCKS5 soa non chega. |
| Require SOCKS4 | Un punto SOCKS4 compatible e o modo de cliente correspondente. |
| Non admite proxys | Unha IP da lista non configura a aplicación por si soa. |
Para peticións web e API adoita abondar un proxy HTTP. Reenvía HTTP e, cando se permite, transporta HTTPS por CONNECT. Unha páxina HTTP simple que funciona non proba soporte de túneles: o servizo pode esixir autenticación do túnel ou limitar destinos e portos.
SOCKS traballa por debaixo da capa de peticións HTTP. Unha aplicación compatible pídelle establecer unha conexión sen interpretar unha petición HTTP, polo que tamén serve para outro tráfico admitido. SOCKS5 define enderezos IPv4, IPv6 e de dominio, autenticación e asociación UDP. Unha aplicación ou un punto gratuíto concreto pode implementar só parte das funcións. A ruta TCP SOCKS do navegador non cobre automaticamente outra aplicación ou servizo UDP.
Onde se resolve o nome do destino?
En curl, a escrita do URL SOCKS5 determina onde se resolve o DNS do destino: socks5:// resolve localmente; socks5h:// pídeo ao proxy. Vistas DNS distintas poden facer que unha opción funcione e a outra falle. Outros clientes poden usar unha caixa ou unha opción separada. Escoller SOCKS5 non demostra que cada consulta DNS pase por el.
SOCKS4 ten menos funcións; SOCKS4a engade o tratamento de nomes de host. Se cliente e servizo admiten SOCKS5 e non hai razón para o protocolo antigo, unha entrada SOCKS5 axeitada é unha primeira escolla razoable. Un punto SOCKS4 co cliente en modo SOCKS5 é unha incompatibilidade de protocolo.
Cando o protocolo encaixe, proba o destino real e identifica o primeiro fallo. Nin HTTP nin SOCKS5 mide o anonimato: a confianza no operador, TLS do destino e a ruta real da aplicación seguen determinando a protección.