HTTP proxy traffic · pay per GB
HTTP proxies for HTTPS requests.
Buy HTTP proxy traffic for your browser or HTTP client. Connect through a shared mobile 4G/5G or residential pool, with the country and rotation selected in your username. One credential and GB balance cover both pools.
Connection format
An HTTP gateway can carry an HTTPS request.
Set the proxy server to http://gw.portproof.org:7000. Keep https:// on an HTTPS destination URL. The two schemes describe different connections: the first reaches the gateway; the second identifies the website your client requests.
- Proxy server
http://gw.portproof.org:7000- Proxy authentication
- The full generated username and your proxy password
- HTTPS destination
- Reached through an HTTP CONNECT tunnel
- Pool and country
- Selected in the username from current availability
For an HTTPS destination, the client asks the proxy to open a CONNECT tunnel, then establishes TLS with the destination through it. Keep certificate verification enabled. The HTTP CONNECT specification describes the tunnel; a successful tunnel response is separate from the website’s response.
This HTTP gateway connection does not encrypt Basic proxy credentials or the CONNECT destination hostname. HTTPS protects the destination exchange when certificates are correctly verified and there is no trusted TLS interception. If your environment requires TLS to the proxy itself, confirm that requirement before buying: changing the gateway prefix to https:// does not add it. Chrome’s proxy documentation distinguishes these connections.
Terminology
An “HTTPS proxy” is usually an HTTP proxy.
A client setting, job specification or HTTPS_PROXY variable that asks for an HTTPS proxy usually means the proxy used for https:// destinations. Its value is still an HTTP gateway address, here http://gw.portproof.org:7000. In a local test run, Python Requests read an HTTPS_PROXY value beginning with http:// and completed an HTTPS request through the proxy.
1 client → gateway CONNECT example.com:443 HTTP/1.1, with Proxy-Authorization
2 gateway → client HTTP/1.1 200: the tunnel is open
3 client ⇄ website TLS handshake, then GET / (the website sees exit 203.0.113.x, example)Lines 1 and 2 are plain HTTP between your client and the gateway; line 1 names the destination host and port and carries your proxy credentials. From line 3, TLS runs between your client and the website inside the tunnel. The gateway relays that exchange, and your client checks the website’s certificate exactly as it would without a proxy. The address in line 3 is an example from a documentation range.
A proxy URL that starts with https:// asks for something else: TLS between your client and the proxy itself. In the same run, curl 8.7.1 given an https:// proxy URL for a plain-HTTP proxy port failed in the TLS handshake with the proxy, before any CONNECT was sent. Use the gateway address exactly as the connection builder prints it.
Your HTTPS sites need no other product: they work through this HTTP port. Choose SOCKS5 when your client requires it, or for a permitted non-HTTP TCP workflow once you have checked that the destination, port and authentication are supported; the HTTP and SOCKS5 guide compares the two. Both protocols draw on the same balance at the current price per GB.
The traffic you buy
Choose the network for the observation.
Residential
Use the residential pool for a permitted check that calls for a peer-network connection. Its opt-in devices use a mix of home broadband and mobile connections. Check the country you need before ordering; a device shown online now can later disconnect.
Mobile 4G/5G
Use the mobile pool when your test needs a carrier-network exit. Set browser layout, language and account state separately. A mobile network address does not select a phone viewport or determine the content a website will show.
Both pools are shared. Your order adds traffic to a balance; it does not reserve an exit address. Use current locations to check the route, and decide whether the task can tolerate interruptions. HTTP and SOCKS5 use the same balance, so choose the protocol your application supports.
Before ordering
Check how your application accepts credentials.
Look for authenticated HTTP proxy support and HTTPS tunnelling in the exact client you run. Keep destination login details separate from proxy authentication. Use dedicated username and password fields where provided; a proxy address field alone may not accept credentials embedded in a URL.
Browser checks
The Playwright guide configures the browser and its proxy credentials. Use a small authorised navigation before a longer QA journey. A working terminal request does not configure browser contexts.
Python collection
Follow the Requests or HTTPX example for your library. Keep its timeout and response limits while checking the route; assess the returned content before increasing concurrency.
Node.js jobs
Use the Node.js fetch or Axios guide for explicit proxy configuration. Client versions and proxy interfaces differ, so carry the whole documented setup into your application.
Other HTTP clients
The Go HTTP client guide covers a transport configuration. For a manual API check, follow Postman’s proxy settings. Compare protocols in the HTTP and SOCKS5 guide.
A useful first check
Verify the route, then the actual job.
- In the connection builder, choose HTTP, an available pool and country, and the session mode. Copy the full username. Keep the password out of screenshots, shared logs and destination headers.
- Run the bounded curl echo check. It prompts for the password and separates CONNECT from destination status. Inspect the response; an echo result describes that connection, not a future request.
- Make one small permitted request from the application you intend to use. Keep TLS verification and request limits. Record whether the expected content arrived, how much data moved and whether another attempt was needed.
For independent observations, per-connection rotation can suit the job. HTTP clients can reuse connections, so a new request does not necessarily select a new exit. For a multi-step journey, use a named sticky session and retain the required application state. The device may disconnect or its IP may change. The session guide explains these choices.
Pay per GB
Price the completed task, including retries.
| Order size | Per GB | Saving | Example total |
|---|---|---|---|
| 1 to 4 GB1 GB = EUR 4.50 | EUR 4.50 | ||
| 5 to 24 GB5 GB = EUR 19.50 | EUR 3.90−13 % | ||
| 25 to 49 GB25 GB = EUR 87.50 | EUR 3.50−22 % | ||
| 50 to 99 GB50 GB = EUR 160.00 | EUR 3.20−29 % | ||
| 100 to 249 GB100 GB = EUR 290.00 | EUR 2.90−36 % | ||
| 250 GB and more250 GB = EUR 625.00 | EUR 2.50−44 % |
Try the real workflow
The current paid trial is 0.5 GB for EUR 2.90, once per customer. Use the trial checklist to decide what a useful result must contain.
Review the paid trial →Measure before scaling
Count complete observations and transferred bytes, including browser resources and retries. Plan with the bandwidth calculator, then reconcile the estimate with account usage. Client measurements and the billing meter can differ.
GB never expire. Review order conditions and payment options before adding traffic. One balance covers HTTP and SOCKS5 across both shared pools.
When a check fails
Find the stage that failed before retrying.
A proxy authentication response calls for checking the full username and password; use the 407 guide. A refused tunnel needs the CONNECT checks. A website response after a working tunnel needs its own interpretation. Repeated retries can consume traffic without producing a useful observation.
Keep the operation within your authorised research, price-monitoring, verification or QA workflow and the acceptable-use policy. Follow destination access rules and stop when access is refused. Proxy traffic supplies a network route; you choose and run the application that collects or verifies the result.