Is the egress IP truly static — does it ever change?

The egress IP is fixed for as long as the proxy exists on your account. It is reserved when you create the proxy and stays bound to it across stops and restarts. If infrastructure maintenance ever requires an IP reassignment, Nodetonet notifies you in advance through the panel and by email so you can send the new IP to your partner before the change.

Can I have one egress IP for Europe and a separate one for the US on the same account?

Yes. Each proxy you create is bound to one edge server, and each edge has its own static IP. Create two proxies in different regions, give the partner both IPs to whitelist, and point each environment at the correct proxy using its credentials. The Nodetonet panel shows the egress IP on each proxy detail page.

Does setting HTTPS_PROXY affect all requests in a process or only some?

The HTTPS_PROXY environment variable is respected by most standard HTTP clients — curl, Node.js http/https modules, Python requests, Go net/http, and many others. However, some libraries require you to pass the proxy explicitly in code rather than reading the environment variable. Check your library's proxy documentation. For test frameworks, most honour the variable at the process level.

What happens if the tunnel goes down mid-test?

In-flight requests through the tunnel at the moment of disconnection will receive a connection error, just like any interrupted TCP connection. Nodetonet edges run redundant infrastructure, but no system guarantees zero downtime. For CI pipelines, build in a retry mechanism in your test suite or use an API client with automatic retries. The tunnel health monitoring guide explains how to set up alerts.

Can multiple teammates share the same tunnel without sharing credentials?

Yes. Create multiple proxy tokens under the same egress proxy. Each token has independent username and password credentials, its own optional IP allowlist, quota and expiry date. Revoking one token does not affect the others, and the egress IP the partner whitelisted remains unchanged. See the per-client auth guide for setup steps.

Does this work for APIs that use HTTPS with certificate pinning?

For standard HTTPS where the client verifies the server certificate, yes — the tunnel proxies the TLS connection transparently. For mutual TLS (mTLS) where the server verifies a client certificate pinned to your origin, the proxy cannot help because the mTLS handshake is between your client and the server directly. Routing the IP is fine; the TLS layer sees the tunnel host, which breaks pinning.

Do I need to install any software on my laptop or CI machine?

No. The tunnel is a standard HTTP/HTTPS proxy endpoint. You configure the HTTPS_PROXY environment variable (or the equivalent proxy setting in Postman, your test framework, or your language's HTTP client) and everything routes through it automatically. No agent, no VPN client and no kernel module are needed on the client side.

Nodetonet for API testing — a stable egress IP for whitelisted third-party APIs

Some APIs only let you in if you call them from a whitelisted IP address. Banking sandboxes, payment processors, government registries, KYC providers, regulated-data feeds, internal partner APIs — all of them say "send us the source IPs you will be calling from, and we will allow those; everyone else gets a 403." That policy is reasonable in production, where your servers have known static IPs. It becomes a productivity trap the moment you try to test, debug or iterate from anywhere that isn't your production cluster.

TL;DR — Nodetonet gives your laptop, CI and preview deploys a shared static egress IP that you whitelist once with the partner and reuse across every environment.

The problem with IP-whitelisted APIs

You hit the whitelist wall in at least four places:

Your laptop. DHCP means a new IP every cafe, hotel or co-working space. The partner API blocks you before your first curl lands.
GitHub Actions / GitLab CI. Hosted runners draw fresh ephemeral IPs from a cloud provider pool on every job. Whitelisting the entire provider block defeats the purpose of whitelisting.
Preview and staging deploys. Railway, Render, Fly.io and similar platforms do not guarantee a stable egress IP on lower tiers. Each deploy can bring a new address.
Remote teammates. A developer in another city or country cannot reach the partner API at all during local debugging.

The usual workarounds — mocking the API, routing debug traffic through the production cluster, or persuading the partner to widen their whitelist — each come with their own costs: lost test fidelity, security risk, or slow partner communication cycles.

How Nodetonet solves it

Nodetonet's HTTP tunnels give you an HTTPS endpoint backed by a fixed edge-server IP. Every request you send through the tunnel egresses from that same IP regardless of where you are physically located or which CI runner happens to execute your job. You whitelist the Nodetonet edge IP with the partner once, and the configuration holds across laptops, CI systems and deploys without any further partner communication.

Because billing is prepaid credit with no monthly subscription, you only pay for tunnels that are actively running. Shut one down on a Friday afternoon and it costs nothing over the weekend. The IP is reserved to your account while the proxy exists, so you get the same address back when you restart.

For teams that also need rotating mobile IPs for scraping or geo-verification alongside their static API tunnel, Nodetonet handles both from one panel — see mobile proxies and rotating proxies for those workloads.

Static egress vs common alternatives

Here is how the main approaches to this problem compare:

Approach	Static egress IP?	Works in CI?	Works on laptop?	Extra setup
Nodetonet tunnel	Yes — fixed edge IP	Yes — one env variable	Yes — any network	Create proxy, set HTTPS_PROXY
AWS NAT Gateway	Yes — Elastic IP	Only if runner is inside VPC	No	VPC, subnets, route tables
ngrok / Cloudflare Tunnel	No — inbound tunnels only	No outbound static IP	No outbound static IP	Not applicable for this use case
VPN to prod cluster	Borrows prod IP	Complex key management	Yes, with VPN client	Security review needed
Widen partner whitelist	N/A	Yes	Yes	Partner approval, security risk

ngrok and Cloudflare Tunnel solve a different problem — they expose a local port to the internet (inbound). They do not provide a stable outbound egress IP, which is what IP-whitelisted API testing requires. See our comparison pages for Nodetonet vs ngrok and Nodetonet vs Cloudflare Tunnel for detail.

Step-by-step setup

Create a free account at Nodetonet and add prepaid credit.
In the panel, create an HTTP/HTTPS proxy and select the edge server closest to the partner API — Istanbul for most Turkish APIs, Frankfurt for EU, or a US edge for American partners.
The proxy detail page shows the static egress IP. Copy it and send it to the partner for whitelisting. This is the only time you need to contact them about IPs.
Generate a token on the Tokens page. The token ID and secret are the proxy credentials your clients will use.
Configure your HTTP client, test runner or CI environment to route through the tunnel using the HTTPS_PROXY environment variable (see code examples below).

From this point, every environment that sets HTTPS_PROXY to your tunnel exits from the whitelisted IP, regardless of where it runs.

Code examples

curl — ad-hoc debugging from any machine:

export HTTPS_PROXY="http://TOKEN_ID:TOKEN_SECRET@proxy.nodetonet.com:8443"

curl -sS https://partner-api.example.com/v1/accounts   -H "Authorization: Bearer $PARTNER_API_KEY"   | jq .

The partner API sees the Nodetonet edge IP, not your current network's address.

GitHub Actions — integration job with stable egress:

jobs:
  integration:
    runs-on: ubuntu-latest
    env:
      HTTPS_PROXY: "http://${{ secrets.NTN_TOKEN_ID }}:${{ secrets.NTN_TOKEN_SECRET }}@proxy.nodetonet.com:8443"
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm test

Store NTN_TOKEN_ID and NTN_TOKEN_SECRET as repository secrets. Every fetch, axios call and curl inside npm test will egress from the whitelisted IP.

Postman: Settings → Proxy → Use custom proxy configuration. Proxy server: proxy.nodetonet.com, port: 8443. Enable authentication, paste token ID as username and secret as password. Every request in the collection, including the runner, uses the whitelisted IP.

Python requests library:

import requests, os

proxies = {
    "https": f"http://{os.environ['NTN_TOKEN_ID']}:{os.environ['NTN_TOKEN_SECRET']}@proxy.nodetonet.com:8443"
}
resp = requests.get("https://partner-api.example.com/v1/accounts",
                    headers={"Authorization": f"Bearer {os.environ['PARTNER_KEY']}"},
                    proxies=proxies)
print(resp.json())

Per-client controls and security

If your team is large, or if you share the tunnel with a contractor, you can create separate tokens with independent credentials, IP allow/deny lists, bandwidth quotas and expiry dates. Revoking a token does not affect the others or the whitelisted IP. Read more about per-client authentication and quota limits in our blog.

For an audit trail of who used the tunnel and when, see audit logs. For SOCKS5-based testing of non-HTTP services, see our SOCKS5 proxy feature page.

When this is not the right fit

You need many different egress IPs across many countries. That is a rotating-proxy or mobile-proxy use case. See rotating proxies or mobile proxies.
The partner requires a specific cloud-provider ASN such as "AWS only" or "Azure only." Nodetonet edges run on independent data-centre infrastructure, not hyperscalers. You would need a NAT Gateway inside the required cloud instead.
Mutual TLS pinned to your origin certificate. A proxy cannot help here — by design, mTLS terminates at the origin, not at the proxy layer.
Pure inbound exposure — you want to give the partner a URL that calls back into your local server. That is an inbound tunnel, which Nodetonet's HTTP tunnel feature also covers; this page focuses on the outbound-egress direction.

For most third-party API testing — fintech sandboxes, KYC providers, government registry APIs, payment processors, regulated-data feeds — one tunnel with a fixed egress IP and one whitelisting request to the partner is all you need. Verify your current IP anytime with our free IP checker or validate proxy connectivity with the proxy checker.