HTTP, HTTPS and SOCKS5
How NyxonProxies carries HTTP, HTTPS and SOCKS5 traffic, which port each uses, where DNS is resolved and why the proxy URL starts with http:// for HTTPS sites.
Every NyxonProxies product speaks two proxy protocols: HTTP and SOCKS5. HTTPS is not a third protocol here. It is your normal encrypted traffic, carried through the HTTP proxy in a tunnel. The same username and password work for both protocols.
HTTP proxy
Use the HTTP port when your client talks to websites or APIs. It handles two kinds of traffic:
- Plain
http://sites. Your client sends the full request to the gateway, which fetches the page and returns it. https://sites. Your client asks the gateway to open a tunnel to the site with theCONNECTmethod. Once the tunnel is open, the TLS session runs between your client and the website, so the gateway passes encrypted bytes and never sees the page, the headers or the cookies.
Inside the tunnel your client and the site negotiate HTTP/1.1 or HTTP/2 exactly as they would without a proxy.
curl -x http://USERNAME:[email protected]:8080 https://api.ipify.orgWhy the proxy URL starts with http://
The scheme in the proxy URL describes how your client talks to the gateway, not to the website. The gateway accepts plain HTTP proxy connections, so the proxy URL starts with http:// even when every site you visit is HTTPS. Your traffic to the site is still encrypted end to end inside the tunnel.
SOCKS5
SOCKS5 relays raw TCP connections, so it works for clients that are not web browsers or HTTP libraries: chat apps, mail clients, games, SSH, database tools and anything else with a SOCKS5 setting. It authenticates with the same username and password, using the SOCKS5 username and password method.
curl -x socks5h://USERNAME:[email protected]:1080 https://api.ipify.orgHTTPS over SOCKS5 is encrypted end to end in the same way: SOCKS5 only moves the bytes.
Where DNS is resolved
Before a connection opens, someone has to turn the site's hostname into an IP address.
- HTTP proxy: your client sends the hostname to the gateway, and the gateway resolves it. Nothing to configure.
- SOCKS5: it depends on the client. Many let you choose between sending the hostname to the proxy or resolving it locally and sending only the IP.
Remote resolution is usually what you want. Your local DNS requests do not reveal the sites you visit, and the site resolves to the address that fits the exit location, which matters for sites that serve a different IP per region. In curl and in Python libraries, socks5h:// resolves through the proxy and socks5:// resolves locally. In browsers and apps, look for an option named like Proxy DNS when using SOCKS v5 or remote DNS.
Ports
Each product lists one HTTP port and one SOCKS5 port, see Endpoints and ports. On geo.gw.nyxon.sh, used by Residential and Mobile, the ports are strict: 8080 only speaks HTTP and 1080 only speaks SOCKS5. Match the port to the protocol in the URL.
Which one to choose
| Situation | Use |
|---|---|
| Scraping, APIs, HTTP libraries | HTTP |
| Browsers and antidetect profiles | HTTP, or SOCKS5 if the tool supports SOCKS5 with a password |
| Apps that are not web clients | SOCKS5 |
| You want DNS resolved at the exit | HTTP, or SOCKS5 with remote DNS |
| The tool only offers one of them | That one |
Both protocols use the same plan and draw from the same traffic.
Clients without SOCKS5 passwords
Some software supports SOCKS5 but not SOCKS5 with a username and password. Google Chrome is the best-known example: it does not support SOCKS5 authentication. Use the HTTP port with those tools, or a tool that adds the credentials for you, such as Proxifier on the desktop.
Last updated
Still stuck?
People answer the live chat around the clock. Send the proxy line you used (without the password) and the error you see.