IPv4- en IPv6-proxy’s: welke verbinding heeft ondersteuning nodig?
De verbinding van client naar proxy en van proxy naar website kan een andere adresfamilie gebruiken. Controleer beide voordat je een endpoint kiest.
Een IPv6-proxylistener heeft een IPv6-route vanaf je client nodig. De uitgaande verbinding naar een website kan nog steeds IPv4 gebruiken. Andersom kan een IPv4-listener een IPv6-bestemming bereiken als de proxy de nodige ondersteuning en route heeft.
| Verbinding | Vereiste ondersteuning |
|---|---|
| Client → proxy | Een route naar het endpointadres en een bereikbare luisterende dienst. |
| Proxy → bestemming | Een geschikt bestemmingsadres, resolver, uitgaande route en toegangsbeleid op de proxy. |
Zet een letterlijk IPv6-adres in een volledige proxy-URL tussen vierkante haken:
http://[2001:db8::10]:8080Vervang het documentatieadres door het echte endpoint. Aparte host- en poortvelden kunnen het adres zonder haken verwachten; volg het formaat van de app. Correcte syntaxis maakt geen ontbrekende IPv6-route. Controleer daarom de IPv6-status van je netwerk of een andere IPv6-bestemming voordat je de listener de schuld geeft.
Welke kant kiest het bestemmingsadres?
Een CONNECT-verzoek met een hostnaam laat de verbinding naar de bestemming aan de proxy over. SOCKS5 kan afhankelijk van de clientmodus een IPv4-adres, IPv6-adres of domeinnaam doorgeven. Een adresfamilie aan de clientkant afdwingen beperkt niet noodzakelijk een naam die op afstand wordt opgelost; zoek uit welke verbinding die optie beïnvloedt.
Een IP-controle die IPv4 meldt nadat je een IPv6-listener koos, is dus mogelijk zonder tweede clientverbinding. Stel eerst vast of de controle haar TCP-peer, een applicatieheader of een ander browserverzoek weergeeft. Gewone HTTP-doorsturing kan clientadresinformatie toevoegen; een normale CONNECT-relay kan geen header invoegen in het versleutelde HTTP van de bestemming. Forwarded-informatie vereist vertrouwensbeleid en bewijst op zichzelf geen andere netwerkverbinding.
Noteer endpoint, doel, protocol en eerste fout. De listener niet kunnen bereiken is iets anders dan diens antwoord dat de bestemming onbereikbaar is. De verzamelaar achter de ProxyHub-proxylijst accepteert momenteel IPv4-records; deze IPv6-voorbeelden beschrijven algemeen gedrag, geen huidig IPv6-filter in de lijst.