Masked hostnames: how a customer can't tell whose network you sell

2026-10-12 · Bazyl

After this you know exactly what a customer of yours can read out of the proxy string you hand them, and what they can't. Most partners worry in the wrong direction. They worry that the 407 or a DNS lookup gives the network away, and neither does. What does carry a name is the hostname itself, and that one is yours to change.

The string carries our hostname by default

A customer of an API partner gets a string like this: a username under your prefix, a password, and one of our three gateway hostnames.

http://ck_9m2xq7t:[email protected]:4243

Three gateways, one pool: eu-residential2.basilproxies.com, us-residential2.basilproxies.com and ap-residential2.basilproxies.com. Port 4242 rotates, port 4243 is sticky, and the port picks the session model. The exit country comes from the username, not from the gateway, so the gateway choice is about latency.

So, honestly: the word basilproxies is in that string. A customer who reads hostnames knows the gateway is ours. What they cannot read is anything about the network behind it, and the rest of this post is about that line.

What the gateway tells anyone who looks

Connect to a gateway without credentials and it answers a 407 whose challenge names no supplier. This is the transcript, captured on 1 October 2026 against the European gateway:

$ curl -sI -x eu-residential2.basilproxies.com:4242 https://example.com
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="ProxyServer"

The realm is the only place a proxy introduces itself before authentication, and ours says ProxyServer. Nothing more. Reverse DNS on the three gateway addresses answers with a generic cloud hostname, not a Basil name and not any proxy vendor's.

That is the full list of what a curious customer learns from probing: it is an HTTP proxy, it wants Basic auth, the realm says ProxyServer, and reverse DNS gives a generic cloud hostname. The network behind the gateway is not on that list. Not from the string, not from the 407, not from DNS.

Your own hostname is a CNAME

If you don't want our name in the string either, point your own hostname at a gateway. A CNAME from proxy.yourbrand.com to eu-residential2.basilproxies.com is the whole change, and nothing on our side changes with it: same username, same password, same ports.

http://ck_9m2xq7t:[email protected]:4243

API partners get this on request. The hosted white-label plan includes it. In both cases the gateway's answer to a probe stays the transcript above, realm ProxyServer, because the CNAME changes what the customer types and not what answers.

The record lives in your DNS, which is why nothing on our side changes. It also means the hostname is yours to move: a CNAME can point at the US or Asia gateway instead, and the string your customers hold keeps working.

The token syntax is public, hostname or not

A customer who has read our docs recognises the username format whatever hostname sits in front of it. Every targeting token rides the username, in a fixed order: country, then city or ISP, then OS, then session, then lifetime. A sticky German session for an hour looks like this on your own hostname:

http://ck_9m2xq7t-country-de-session-k3j9x2m8-lifetime-60:[email protected]:4243

That syntax is documented on our docs page for anyone to read, so it is not a secret and I don't sell it as one. It tells a reader which format the gateway speaks. It does not tell them whose network answers, and that is the only question this post is about.

Your customer never meets us

Your customer gets no Basil dashboard, no Basil login and no Basil email. The string comes from you, support comes from you, and their money goes to you however you collect it. We see neither them nor it.

The username carries your prefix, ck_9m2xq7t style: a short tag and an id, not a name anyone can look up. A customer with two strings from you sees two usernames that look like a set, and nothing in either points past you.

The password is yours to rotate

The password never changes on its own, and when you want it changed it dies at once. POST /customers/:id/rotate-credentials returns fresh credentials and the old password stops working immediately. kill is suspend plus the same rotation, for the cases where someone needs to be stopped rather than re-keyed.

curl -s -X POST "https://api.basilproxies.com/api/reseller/v1/customers/$CUSTOMER_ID/rotate-credentials?product=residential2" \
  -H "Authorization: Bearer $BASIL_PARTNER_KEY" \
  -H "Idempotency-Key: rotate-1042-2026-10-12"

Two things to tell the customer when you rotate. The old string is dead, so every bot still holding it fails from its next request. And the new one can answer 407 for about a minute while the gateway picks it up; the partner API reports warmupSeconds: 60. A 407 in that window is not a bad password, and your support channel is quieter once your customers know that.

What we don't hide

We don't hide that it is a proxy. The 407 says Proxy Authentication Required because that is what the protocol says, and a customer who runs curl -x sees it. We don't hide the ports, and we don't hide that the default hostname is ours. What stays private is the network behind the gateway, and that is the part that matters when you sell under your own name.

If the string above is one you'd put your brand on, the partner page is where it starts.