An ordinary Nodetonet tunnel will reach anywhere on the public internet. That is fine for most workflows — you point your scraper at one site and ignore that the proxy could, in principle, reach a million others. But "could" is a problem the moment someone else gets the credentials, the moment a script gets a typo in its target hostname, or the moment a regulator asks where your residential bandwidth has been spent.
TL;DR — domain restrictions let you attach a per-proxy firewall to the destination side of every connection, complementing IP allow- and deny-lists on the source side.
Together, source-IP restrictions (who can connect to your proxy) and domain restrictions (where your proxy is willing to go) give you a two-wall sandbox. Breach one wall and the other limits the damage. This guide explains how the two modes work, what the wildcard syntax means, how blocked requests behave, and which real-world patterns work best.
The two modes
Each proxy carries exactly one domain-restriction mode. There are three choices:
| Mode | What it does | Best for |
|---|---|---|
| Off (default) | No domain filter. The proxy dials any hostname the client requests. | General-purpose tunnels with no target constraint. |
| Allow-list | Only hostnames on the list may be reached. Every other destination is blocked at the proxy before a connection attempt is made. | Single-site scrapers, staging sandboxes, compliance-scoped proxies. |
| Deny-list | Every destination is permitted except those on the list, which are refused. | Blocking analytics, ad networks, or sensitive internal infrastructure from a shared tunnel. |
You cannot combine modes — one tunnel, one mode. Switching modes is instantaneous: new connections respect the updated rule immediately, while existing in-flight connections are not torn down. That means you can tighten a rule mid-job without killing the work that prompted you to tighten it.
Where to configure it
Open the proxy you want to restrict in the panel, click Settings, then switch to the Domain Restrictions tab. You will find a mode dropdown and a textarea for entries, one host per line. Hit Save and the rule is live within a second or two for new connections.
The same surface is available through the API, which matters if you manage dozens of proxies programmatically. See the REST API quickstart and the API section below. If you manage large numbers of proxies at once, see bulk operations for patterns that handle hundreds in one call.
Wildcard syntax and matching rules
Each line in the entry textarea is a hostname pattern. Four forms are accepted:
example.com— exact apex match only. Does not matchwww.example.comor any subdomain.*.example.com— matches exactly one DNS label:api.example.commatches, butv2.api.example.comdoes not.**.example.com— greedy wildcard, matches any depth:a.b.c.example.commatches.api.example.com:443— port-specific match, rarely needed but valid.
If you want both the apex and all subdomains, list them on separate lines:
example.com
**.example.comMatching happens on the hostname the client declared, not on the resolved IP. For HTTP CONNECT and SOCKS5 tunnels, that is whatever host the client put in its request. For HTTPS tunnels, it is the SNI field from the TLS handshake. The system never trusts a destination IP to claim it belongs to an allowed hostname — that direction is trivially spoofable.
How blocked requests look
A client that tries to reach a hostname blocked by the current rule does not get a network-level timeout — it gets an explicit proxy-level refusal:
HTTP/1.1 403 Forbidden
X-Nodetonet-Reason: target-not-allowedSOCKS5 clients receive a Rule failure reply with code 0x02. This is distinct from a DNS resolution failure or a connect timeout, which would mean the proxy tried and the target did not respond. A clean 403 means "refused on principle — this destination is not on your list."
Every blocked attempt is logged in the proxy's request log as BLOCKED · domain with the requested host, giving you a complete forensic trail. If your scraper reports it is stuck but the panel shows zero blocked attempts and zero allowed attempts, the request never reached the tunnel at all — check the client's proxy configuration, not the domain list.
Practical patterns
Single-site scraper
Set mode to allow-list with one entry:
**.targetsite.comEven if the credentials are compromised, the attacker can only reach that one domain through the proxy. Combined with IP restrictions on the source side and per-client credentials, this is as locked-down as a single proxy gets.
Staging sandbox
Allow-list with your internal staging hostname:
*.staging.internalA tester assigned this proxy cannot accidentally hit production through the same endpoint. Pair with thread limits to cap concurrency in the test environment.
Block telemetry and ad networks
Set mode to deny-list and add the usual analytics endpoints:
*.google-analytics.com
*.doubleclick.net
*.facebook.net
*.hotjar.comAny device paired through this proxy will not phone home to these services, whether the client app requests it or not. This is a lightweight privacy mode for a shared mobile proxy.
Compliance scope
If you operate in a regulated environment where certain content categories must not transit your infrastructure regardless of what downstream clients request, a deny-list of the relevant domains lets the proxy enforce that rule at the network layer — before the request is ever proxied. Log inspection afterwards is still advisable but the rule is structural, not dependent on log review.
API control
Domain restrictions are fully scriptable. To set an allow-list from the command line:
curl -X PATCH -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" -d '{"domainMode":"allow","domainEntries":["**.targetsite.com"]}' https://nodetonet.com/api/v1/proxies/<id>The domainMode field accepts off, allow, or deny. The domainEntries array uses the same wildcard syntax as the panel. To disable all domain filtering, send {"domainMode":"off","domainEntries":[]}. For provisioning many proxies with matching rules in one pass, see bulk operations and the Python tunnel creation guide.
Domain restrictions vs IP restrictions — which to use
The two restriction types are orthogonal and complement each other:
- IP restrictions — filter the source. Control who may use the proxy. Example: only your scraper server's IP may connect.
- Domain restrictions — filter the destination. Control where the proxy is willing to go. Example: only
**.targetsite.commay be reached.
Apply both simultaneously for maximum containment. Source-IP restrictions stop unauthorized users from connecting at all; domain restrictions limit the blast radius if credentials do leak. Neither replaces the other. See also quota limits and time-limited clients for the remaining per-client controls you can stack on top.
Related features and next steps
- IP allow- and deny-lists — the same idea applied to the source side of the tunnel.
- Per-customer proxy clients — scope domain rules per downstream consumer on a shared tunnel.
- Audit logs — see exactly which hosts have been requested through a tunnel.
- Nodetonet quickstart — the rest of the platform tour.
- All Nodetonet features — the full capability overview.
- Create a free account and try domain restrictions in minutes.