Skip to content

Proxies for authorized security testing

Check that your geo rules, rate limits and WAF policies behave as designed for traffic from other countries, on systems you own or are authorized in writing to test.

Authorized testing only. Test systems you own or have written permission to test.

  1. Your client

    USERNAME:PASSWORD

  2. netdash gateway

    -us or -eu

  3. Exit IP

    -cc-{CC}

  4. Website

    HTTPS via CONNECT

The website sees the exit IP, not your own IP address.
  • Country-level exits by ISO code
  • Static IPs through sales
  • Sticky sessions for per-IP tests

Test your controls from outside your network

Geo rules, WAF country policies and per-IP rate limits are usually checked from the office or from a single cloud region: the one path where they behave as expected. Rules written for other countries go untested until a customer reports them.

Using proxies for security testing means sending your test requests from exit IPs in the countries your rules name, and from known static IPs when you need to find the traffic in your logs. netdash provides the connectivity; the scope, the authorization and the test plan stay with you.

Why source country and IP matter to your rules

Your controls key on the source of a request. Verifying them needs requests from the countries and IP addresses the rules are written for, not only from the network you operate.

Targeting is country-level, so rules for a specific city, network or carrier are outside what you can test this way.

  • Country allow and deny lists
  • Country-specific WAF policies
  • Per-IP rate limits
  • CDN routing and content rules by region

Before you test: authorization and scope

  • Written authorization

    Permission from the system owner, in writing, before any test traffic. If you operate the system yourself, record who approved the test.

  • Defined scope

    Hosts, paths, countries, dates and request volumes. Anything outside the scope is out of bounds.

  • Contacts and stop conditions

    Named people on both sides, and the conditions under which you stop at once.

  • Provider testing policies

    Your hosting, CDN or WAF provider’s testing policy, checked before you start. Some ask for notice before security tests.

  • A test reference ID

    One ID per test run, sent in a header you control, so the traffic is easy to find and attribute.

  • Results handling

    Where logs and findings are stored, who can read them, and how temporary test configuration is removed afterwards.

A rule-verification run

  1. Step 1: Authorize and scope

    Written permission, hosts, countries, dates and volumes, as in the checklist above.

  2. Step 2: Write expectations

    One row per control in the expected-outcome table.

  3. Step 3: Pick exits per test

    Rotating per country for geo rules, sticky 15 for per-IP limits, static IPs for log attribution.

    Sessions
  4. Step 4: Tag the traffic

    Send your own header, e.g. X-Authorized-Test: <test-id>, and record the exit IP per session so logs and report line up.

  5. Step 5: Run at functional volume

    Enough requests to trigger each rule, and no more.

  6. Step 6: Compare and close

    Observed against expected, findings to their owners, temporary test configuration removed.

Expected-outcome table

Expected-outcome table
AttributeTestMode and TTLExpected result
Country deny listA request from a denied countryRotatingThe status your rule returns, e.g. 403 or 451
Country allow listA request from an allowed countryRotating200
Per-IP rate limitN+1 requests from one exit IPSticky, 15429 after N requests
WAF country policyA request matching the policy, from the country it coversRotatingThe action you configured
Log attributionAny testStatic IPs from salesRequests appear under the known IPs and your test header

The expected results are examples. Replace them with what your own configuration specifies.

Proxies for security testing, by test type

The examples use the Scale plan: every residential plan uses the same syntax, and you switch plans by changing the host and port. Country targeting and the proxy string format explain each part.

Geo rule, Americas

scale-us.netdash.io:2000 · USERNAME-cc-US

Rotating: no session parameters.

Geo rule, Europe

scale-eu.netdash.io:2000 · USERNAME-cc-DE, USERNAME-cc-GB

Rotating. Use GB, not UK.

Per-IP rate limit

scale-eu.netdash.io:2000 · USERNAME-cc-GB-session-{SID}-ttl-15

Sticky, 15 minutes: the requests in one test share an exit IP while it stays available.

Session ID (`SID`)

First 8 hex characters of a hash of the test reference ID

Letters and digits only, no hyphens.

Log attribution, repeatable runs

Static ISP or datacenter IPs from sales

Delivered as a host:port:user:pass list with credentials for that order. The IPs stay assigned while the subscription renews, billed per IP every 30 days.

A table-driven check in Go

Each case names an exit country, the gateway it pairs with and the status your rule should return. Every request carries your agreed reference ID in X-Authorized-Test, so it is easy to find in your logs, and the test skips itself unless credentials and a test ID are set.

url.UserPassword sets the proxy username, with its -cc- parameter, and your password; http.ProxyURL sends every request through that gateway, and HTTPS requests go through a CONNECT tunnel.

  • One request per case: enough to confirm the rule, run inside the agreed test window
  • For a per-IP limit, add -session-{SID}-ttl-15 and send N+1 requests through one client
  • More on clients in the Go guide and the Python guide
package geocheck

import (
	"net/http"
	"net/url"
	"os"
	"testing"
	"time"
)

// Expected statuses are examples of your own rules: replace them with what your configuration specifies.
var cases = []struct {
	CC, Host string
	Want     int
}{
	{"US", "scale-us.netdash.io:2000", http.StatusOK},
	{"DE", "scale-eu.netdash.io:2000", http.StatusUnavailableForLegalReasons},
	{"GB", "scale-eu.netdash.io:2000", http.StatusOK},
}

const target = "https://app.yourcompany.example/geo-check" // a system you own or are authorized to test

func TestGeoRules(t *testing.T) {
	user, pass := os.Getenv("NETDASH_USERNAME"), os.Getenv("NETDASH_PASSWORD")
	testID := os.Getenv("AUTHORIZED_TEST_ID") // the reference agreed with the system owner
	if user == "" || pass == "" || testID == "" {
		t.Skip("set NETDASH_USERNAME, NETDASH_PASSWORD and AUTHORIZED_TEST_ID")
	}

	for _, c := range cases {
		t.Run(c.CC, func(t *testing.T) {
			proxyURL := &url.URL{Scheme: "http", User: url.UserPassword(user+"-cc-"+c.CC, pass), Host: c.Host}
			client := &http.Client{
				Transport: &http.Transport{Proxy: http.ProxyURL(proxyURL)},
				Timeout:   30 * time.Second,
			}

			req, err := http.NewRequest(http.MethodGet, target, nil)
			if err != nil {
				t.Fatal(err)
			}
			req.Header.Set("X-Authorized-Test", testID)

			resp, err := client.Do(req)
			if err != nil {
				// A 407 from the gateway (wrong username or password) also ends up here.
				t.Fatalf("exit %s via %s: %v", c.CC, c.Host, err)
			}
			defer resp.Body.Close()

			if resp.StatusCode != c.Want {
				t.Errorf("exit %s: got %d, want %d", c.CC, resp.StatusCode, c.Want)
			}
		})
	}
}
Go

Which product for which control

  • ISP proxies

    Through sales

    A fixed, known list of static IPs in Ashburn, Frankfurt, London and Sydney that your team can recognize in logs and reuse for repeatable tests.

    $1.60 per IP per 30 days

  • Datacenter proxies

    Through sales

    Static IPs in the US, Germany, the UK and the Netherlands, for checking how your rules treat datacenter traffic.

    $1.40 per IP per 30 days

  • Residential proxies

    Self-serve

    Exits in the countries your geo rules cover, self-serve, with sticky sessions when a test needs one IP.

    From $1.20/GB, graduated per order

What this page doesn’t cover

netdash is not for scanning or probing systems you don’t own or aren’t authorized to test, testing credentials or logins, load or stress testing, or getting past other people’s challenges or access controls. Run load tests from infrastructure you control.

Section 2 of our Terms of Service lists among prohibited uses: "Any illegal activities, including but not limited to fraud, identity theft, money laundering, or cyberattacks." and "DDoS attacks, flooding, or any other form of network disruption or interference." If you see netdash traffic probing your systems without authorization, report misuse.

Authorized systems only

Only test systems you own or operate, or systems whose owner has given you written permission, within the agreed scope. Keep volumes to what each test needs. Testing other people’s systems without authorization is not what netdash is for. See how we expect netdash to be used.

Security testing questions

Systems you own or operate, or systems whose owner has given you written permission for a defined scope. This isn’t legal advice; check what your contracts and jurisdiction require.

No. Run functional checks through netdash and generate load from infrastructure you control. Never scan systems you aren’t authorized to test.

Tag requests with your own header and record the exit IP per session. Static ISP or datacenter IPs from sales give you a fixed list in advance.

No. Targeting is country-level, and carriers or networks can’t be selected.

Check their testing policy; some ask for notice before security tests. Agree contacts and stop conditions with the system owner first. For questions about netdash itself, contact us.

Plan an authorized test

Tell sales which countries and how many static IPs your test plan needs, or create an account to start with residential exits.

Privacy choices

We use cookies and similar technologies that this site needs to work and to remember your choice. We also use Google Analytics to understand which pages and features people use: in the EEA, the UK and Switzerland only with your consent. Live chat loads only if you open it. You can change your choice at any time under “Privacy choices” in the footer. Privacy Policy

Privacy choices

Choose what netdash.io may use. You can change this at any time under “Privacy choices” in the footer.

Necessary (always on)

Keeps the site working and secure, and remembers your privacy choices (nd_consent, 12 months).

In the EEA, the UK and Switzerland it stays off until you switch it on; elsewhere it is on unless you switch it off here. Google Analytics 4 measures page views, clicks on links and buttons, use of the price calculator, connection builder and code examples, scroll depth, file downloads, and page-performance metrics. It sets the cookies _ga and _ga_96MPNM6GHH, which last up to 12 months. Google processes this data, which may involve transfer to the United States. We do not send your name, email address or account details to Google Analytics. With this switched on we also remember a referral code or campaign you arrived with (nd_attr, 30 days), so a partner can be credited if you sign up.

Support chat (loads only when you open it)

Our live chat is provided by LiveChat. It loads only when you open the chat window. LiveChat then sets its own cookies and processes the messages you send and technical data about your browser.