ScreenshotNeo

BlogGuides

Can Browshot Capture Websites Behind a Proxy or Firewall?

Browshot documents login automation and IP allowlisting for private content, but its public docs do not establish customer proxy or private-network routing. Here is what to verify before relying on it.

By the ScreenshotNeo team4 October 202610 min read

Short answer: Browshot documents ways to capture pages that require application-level login, and its password-protected-pages page says customers can whitelist Browshot IPs to access private content. That may help when a firewall can allow connections from Browshot to an otherwise reachable origin. However, the public documentation reviewed does not establish that a Browshot browser can use your customer-specific proxy, join your LAN, or tunnel through your firewall. Do not assume that a private Browshot instance runs inside your network. Confirm the exact network route with Browshot before depending on this setup.

The key distinction is application access versus network access. Cookies, login steps, headers, and POST data address what the browser does after it can reach a site. A proxy route, firewall rule, or private-network connection determines whether the browser can reach the host at all. Browshot documents the former and IP allowlisting for private content; it does not publicly explain a customer-specific proxy or tunnel.

What Browshot documents

Need Documented capability What remains to confirm
Capture a public URL The screenshot API accepts a target URL and browser instance. It supports settings including screenshot size, cache, delay, and callbacks. Whether the selected instance can resolve and reach your particular host.
Reach private content through an allowlist Browshot’s password-protected-pages page says you can contact it for its IPs to whitelist. Which source IPs apply to your account and region, whether they are stable, and whether your origin’s DNS, port, TLS, and routing are reachable from those IPs.
Sign in to a reachable application Automation steps can click, type, navigate, wait, run JavaScript, and capture. Documentation also describes basic authentication and session cookies. The site’s specific authentication flow, session lifetime, MFA, and any application restrictions.
Use a private instance or server Browshot describes private browsers/instances for high-volume or custom-browser needs, and private servers. The reviewed description does not say these are deployed inside your network or connected to your LAN or proxy.
Test public geographic variants Browshot lists browser IP locations such as Germany, the UK, the USA, and Australia, with other countries available by inquiry. A geographic IP choice is not evidence of a route into a private network.

Sources: Browshot API documentation, features and pricing, password-protected pages, and login automation guide. These describe hosted capture, account access options, and allowlisting; they do not document customer-specific proxy tunneling.

First determine what “behind a firewall” means

  1. Public host, login required: The browser can reach the hostname, but the app requires credentials or a session. Investigate Browshot’s documented login automation, cookies, or authentication options.
  2. Private origin with firewall allowlisting: The origin is routable from the public internet but rejects unapproved source addresses. Ask Browshot for the applicable egress IPs and confirm whether your firewall can allow them. Test DNS, port, TLS, redirects, and the exact URL.
  3. Internal-only hostname or private address: The origin resolves or responds only from your corporate network. Public documentation does not establish that Browshot can reach it. Ask whether Browshot can provide a customer-specific proxy, tunnel, or deployment arrangement.
  4. Outbound proxy required: Your environment requires traffic to pass through a particular proxy. The reviewed documentation does not establish that you can configure such a proxy for Browshot’s browser. Ask directly before designing around it.

How to verify the route before building around it

  1. Write down the exact scheme, hostname, port, and path to capture. Include any redirect destinations and whether the hostname is public DNS, split-horizon DNS, or an internal name.
  2. Classify the restriction: login, source-IP allowlist, private DNS/routing, mandatory outbound proxy, VPN, or a combination.
  3. For an allowlist case, contact Browshot for the exact browser egress IPs relevant to the instance and region you plan to use. Confirm whether those addresses can change and how changes are communicated.
  4. Ask Browshot specifically whether the proposed instance can reach that hostname and port, and whether it supports the required proxy or network arrangement. “Private instance” alone does not answer this.
  5. Run a capture against the exact URL and authentication sequence in a suitable account. Check the final URL after redirects and inspect the returned status/error, not merely whether the API accepted the request.
  6. Repeat the capture after any firewall, DNS, certificate, login, or redirect change. A previously successful screenshot does not prove that a later route or session still works.

Questions to send Browshot

  • Can the browser instance for my account reach hostname:port from its network?
  • Can you provide the source IP addresses to allowlist for this instance and region? Are they fixed?
  • Does this use case require a public origin reachable by allowlisting, or can you configure a customer-specific proxy, tunnel, or deployment inside our network?
  • Can the browser resolve our internal DNS name, follow our redirect chain, and validate our TLS certificate?
  • Which authentication method and automation steps are supported for this flow, and how should credentials or session cookies be supplied securely?
  • Can we test the exact hostname, port, authentication sequence, and redirect behavior before committing to production use?

Runnable Browshot request for a reachable page

This example requests an ordinary hosted capture. It demonstrates the API call; it does not create a proxy route, firewall exception, VPN, or LAN connection. Replace the example URL and instance ID as appropriate. Keep the API key out of source control and logs. See the Browshot API documentation for current parameters and response behavior.

cURL

export BROWSHOT_KEY='YOUR_API_KEY'
curl -G -L 'https://api.browshot.com/api/v1/simple' \
  --data-urlencode 'url=https://example.com/' \
  --data-urlencode 'key='"$BROWSHOT_KEY" \
  --data-urlencode 'instance_id=12' \
  --data-urlencode 'size=page' \
  -o screenshot.png

The simple API may redirect while capture is in progress, so follow redirects. Check the resulting file and response headers: an HTTP success from an intermediate step alone is not proof that the page content is the expected final capture.

Python

import os
import requests

params = {
    "url": "https://example.com/",
    "key": os.environ["BROWSHOT_KEY"],
    "instance_id": 12,
    "size": "page",
}
response = requests.get(
    "https://api.browshot.com/api/v1/simple",
    params=params,
    allow_redirects=True,
    timeout=(10, 180),
)
response.raise_for_status()
content_type = response.headers.get("Content-Type", "")
if "image/" not in content_type:
    raise RuntimeError(
        f"Expected an image, got Content-Type={content_type!r}; "
        f"body starts with {response.text[:300]!r}"
    )
with open("screenshot.png", "wb") as output:
    output.write(response.content)
print("Saved screenshot.png", len(response.content), "bytes")

Install the dependency with python -m pip install requests, then set BROWSHOT_KEY in the environment before running the script.

Node.js

const key = process.env.BROWSHOT_KEY;
if (!key) throw new Error('Set BROWSHOT_KEY first');

const params = new URLSearchParams({
  url: 'https://example.com/',
  key,
  instance_id: '12',
  size: 'page',
});
const response = await fetch(
  `https://api.browshot.com/api/v1/simple?${params}`,
  { redirect: 'follow', signal: AbortSignal.timeout(190_000) }
);
if (!response.ok) {
  throw new Error(`Browshot returned HTTP ${response.status}: ${await response.text()}`);
}
const type = response.headers.get('content-type') || '';
if (!type.startsWith('image/')) {
  throw new Error(`Expected an image; received Content-Type ${type}`);
}
const fs = await import('node:fs/promises');
await fs.writeFile('screenshot.png', Buffer.from(await response.arrayBuffer()));
console.log('Saved screenshot.png');

Run with a Node.js version that provides global fetch and AbortSignal.timeout, setting BROWSHOT_KEY in the environment.

Login automation is not network access

When the browser can already reach the site, Browshot documents automation steps such as clicking a selector, typing into a field, waiting, navigating, and taking a screenshot. Its login guide shows these steps being passed as JSON to the screenshot creation API. This can handle some ordinary login flows; it cannot make an unreachable hostname routable or bypass a firewall.

[
  {"command": "click", "element": "#login"},
  {"command": "type", "element": "#username", "value": "YOUR_USERNAME"},
  {"command": "type", "element": "#password", "value": "YOUR_PASSWORD"},
  {"command": "click", "element": "#submit"},
  {"command": "sleep", "value": "3"},
  {"command": "navigate", "value": "https://example.com/dashboard"},
  {"command": "screenshot"}
]

Use placeholders in examples and protect real credentials. Before using credentials or session cookies, confirm the supported account workflow and consider the sensitivity, scope, and expiration of the credentials. MFA, bot challenges, device approval, and short-lived sessions may need a different workflow and should be tested explicitly.

Common problems and fixes

Symptom Likely cause What to check or do
Domain unreachable or capture fails to load The browser cannot resolve or connect to the origin; a firewall, private DNS, route, port, or proxy requirement may be involved. Verify hostname, DNS visibility, port, routing, and allowlisting from Browshot’s network. Ask Browshot about the exact route. Do not treat login automation as a fix for network reachability.
API returns an error instead of an image Invalid key or URL, insufficient balance for the selected instance, failed page load, or another capture error. Inspect the HTTP status, response body, and documented error header. Correct the request or resolve reachability before retrying.
HTTP 302 response or delayed capture The simple endpoint can redirect while the screenshot is in progress. Follow redirects, allow a realistic timeout, and inspect the final response. For asynchronous flows, use the documented create/status/download API sequence.
Screenshot shows a login page Credentials were not accepted, selectors changed, the session expired, or the site redirected to another login flow. Test each automation step in order, verify selectors and final URL, and increase waits only where the application needs time. Check whether the site requires MFA or another interactive step.
Login works locally but not in capture The service’s browser may not share your local cookies, DNS, network, or trusted device state. Supply a supported session or automation flow; separately confirm the browser can reach the host. Local browser access is not evidence of remote browser access.
Private instance assumed to be inside your network “Private” refers to a service offering or browser/server arrangement; the public feature description does not specify LAN deployment. Ask Browshot to confirm deployment location and network path in writing for your use case.
Wrong regional or cached page Geographic IP selection or cache may affect the returned content. Choose the supported browser location that matches the test and set cache behavior deliberately. Geographic selection does not grant private-network access.

Performance, reliability, and cost considerations

  • Reachability comes first: A faster browser or higher-volume private server cannot capture a host that its network cannot resolve or reach.
  • Use caching intentionally: Browshot’s API documents a cache parameter, with a default cache period described in the API reference. A cache hit can be useful for repeated public-page captures, but it can hide changes in access or page state. Disable or shorten caching while diagnosing access and when fresh content is required.
  • Plan for asynchronous work and redirects: A capture can take longer than an ordinary API call. Follow redirects where required and select timeouts suited to the documented workflow. Check the final result rather than treating request acceptance as success.
  • Choose delay based on the page: Browshot documents a post-load delay setting. A longer delay can allow client-side content to settle but increases elapsed time. It does not resolve blocked network requests.
  • Budget by instance and outcome: Browshot’s documentation says private and shared instance requests require positive balance and describes a free allowance on its feature/API pages. Pricing, quotas, and instance details can change; check the current Browshot account and pricing page before forecasting costs. The reviewed materials say failed screenshots are not charged, but confirm the terms for the instance you use.
  • Make retries bounded: Retry transient timeouts with backoff, but do not repeatedly submit the same unreachable private host. First determine whether the error is a persistent DNS, routing, allowlist, or authentication problem.

Or skip the browser setup

If the page is publicly reachable by a hosted browser, ScreenshotNeo can capture it with one API request. This does not create a route into a private network or replace a required corporate proxy; confirm network access for any protected origin before relying on a hosted capture.

cURL:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python:

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

Node.js:

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

See the ScreenshotNeo API documentation for request options. ScreenshotNeo removes cookie banners, popups, and chat widgets before the shot; bot checks, blank pages, and failed loads are never billed; its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card, and paid plans start at $5 for 3,000 screenshots. Sign up for ScreenshotNeo and get 1,000 free screenshots a month with no card.

Frequently asked questions

Can Browshot capture an internal website?

The public materials reviewed do not establish general access to internal-only hosts. Browshot documents IP allowlisting for private content, which may help when the origin is reachable from its browser network. Ask about your hostname, port, DNS, and route specifically.

Does a Browshot private instance run inside my network?

The public feature description reviewed does not say that it is installed inside a customer’s network. Confirm deployment and connectivity with Browshot.

Can I screenshot a site that requires login?

Browshot documents basic authentication, session cookies, and login automation for reachable pages. That addresses application access, not firewall traversal.

Does choosing a browser country bypass a firewall?

No such capability is documented. Country selection is described as a way to test geographically varied public responses, not as a route into a private network.

What is the safest next step for a firewall-protected origin?

Ask Browshot to confirm the source IPs and network route for your exact hostname and port, then test the complete URL and authentication flow before relying on captures.