Acceptable Use Policy

This policy sets out what you may and may not do with qsa.sh. It forms part of the Terms of Service. In short: scan only your own connecting IP, only when you are authorized, and do not try to work around the controls that keep it that way.

1. Authorization is required

You may scan only a public IP address you own or are expressly authorized to test. The address that is scanned is always the one your connection arrives from, shown to you before the countdown; continuing past the countdown is your confirmation that you are authorized to scan it. This is the same requirement set out in the Terms of Service authorization clause.

This applies equally to paid Full and Deep scans (see Pricing): a token is redeemed by running the command from the server to be scanned, so the target is always your own connecting IP.

2. Prohibited uses

You must not use qsa.sh to:

  • Scan an IP address you do not own or are not authorized to test.
  • Use a proxy, VPN, relay, or any intermediary to present yourself as an IP address you do not control, in order to have that address scanned.
  • Stage, broker, or facilitate scans on behalf of a third party against an address that party is not authorized to test.
  • Attempt to make qsa.sh target any address other than your own connecting address — for example by spoofing CF-Connecting-IP, X-Forwarded-For, or similar headers. This cannot succeed: the target is always the validated connecting IP (technically enforced), and header spoofing does not change it. Attempting it is still a policy breach.
  • Point automated HTTP clients, uptime monitors, or bots at the endpoint to trigger scans. Automated and library User-Agents are not auto-scanned; a scan by such a client requires an explicit, deliberate human opt-in signal.
  • Use automation, scripting, or distributed sources to evade rate limits, the CGNAT/carrier refusal, or the operator deny list.
  • Buy or redeem a scan token to have an address scanned that you do not own or are not authorized to test.
  • Share, resell, or transfer a scan token so that a third party’s address is scanned.
  • Attempt to disrupt, overload, or reverse-engineer the qsa.sh service itself. Report weaknesses instead (see below).

3. CGNAT, carrier, and anonymizer addresses are refused

Connections from shared or anonymizing addresses are refused outright — no scan is run. If your connection arrives from a known carrier-grade NAT (CGNAT, 100.64.0.0/10) or mobile-carrier network, from IPv6 (which we cannot yet reputation-check — run curl -4 qsa.sh), or from an address our reputation data flags as an anonymizing proxy, VPN, or Tor/relay, qsa.sh returns a static “excluded from scanning” response and sends no packets. These reputation checks are best-effort and IPv4-only; your own cloud, hosting, or datacenter IP is not refused.

This is a hard refusal, not merely a tighter limit. Such an address fronts many unrelated third parties, so no single user can truthfully be authorized to have the whole gateway scanned. The refusal is enforced in code at the moment a scan is admitted. Note that this affects only scanning: if you are on a mobile or shared connection you can still freely read every page on this site — browsing is never scanning and is never refused or rate-limited.

These refusals (CGNAT and mobile-carrier ranges, IPv6 origins, connections our data flags as a proxy/VPN/Tor, the opt-out list, and the deny list) apply identically to paid token scans — there is no paid tier that bypasses them.

Owners can also permanently opt an address or range out of scanning entirely; see How to opt out.

4. Rate limits and fair use

Free scanning is limited to 1 scan every 24 hours per IP address; paid token scans have their own per-key cadence (Full: 1 every hour; Deep: bounded by its one-time credit, not a cooldown). All tiers also carry a single-scan-per-address concurrency limit and a global capacity ceiling that protects the scanner fleet. During periods of unusually high aggregate demand across all users, qsa.sh may briefly pause all new scans — returning a “please try again shortly” response and recovering automatically — to keep our outbound scanning within responsible limits. These limits apply to all tiers, including paid token scans. Repeatedly starting and aborting scans, or otherwise generating abnormal load, may tighten your limits. These limits apply only to scan attempts; ordinary browsing of this site is never counted or limited. Do not attempt to circumvent them.

5. Enforcement

We may refuse, throttle, or block any request that breaches this policy, add an address to the operator deny list, and record short-lived, hashed abuse signals to detect repeat abuse. Serious or unlawful misuse may be referred to the relevant provider or authorities. Scan traffic originates from our own real, attributable server IP addresses (a transparent-scanner model — see About), so abuse of the service is traceable to the operator’s infrastructure and taken seriously.

6. Reporting

To report abuse of qsa.sh, or to request that an IP address or range you control be excluded from scanning, use our contact form and choose the Opt-out request subject. To disclose a security vulnerability in qsa.sh itself, use the contact form and choose Security disclosure. We do not operate an inbound email server, so the form is the way to reach us.

7. Zero retention and your responsibility

qsa.sh stores no scan results, no raw IP addresses, no User-Agents, and no scan history — results stream to you and nothing is written to disk (full detail in the Privacy statement). You remain solely responsible for confirming you are authorized to scan the target address before you proceed. The operator additionally bounds scan intensity and refuses CGNAT, mobile-carrier, IPv6, detected-anonymizer, and opted-out addresses as described above; none of that relieves you of the authorization requirement. qsa.sh is provided “as is” and its output is a point-in-time external observation, not a guarantee of security — see the Terms of Service.