Abuse detection FAQ

How JustTunnel's abuse-triage system works, what triggers it, and what happens to your tunnel or account if a rule fires.

JustTunnel runs an abuse-triage pipeline against traffic flowing through tunnels. Its purpose is narrow: detect tunnels being used to host phishing kits, harvest credentials, scan the public internet, or serve content that violates the Acceptable Use Policy. It is not a content filter for legitimate development traffic.

This page is a factual overview. For policy text, see the Terms of Service and Acceptable Use Policy.

What gets inspected

Two phases run on each request that flows through a tunnel:

Inline detection. Runs synchronously in the proxy hot path, panic-safe. Inline detectors are kept cheap so they don't add measurable latency.
Async detection. A non-blocking publisher hands an event to a background worker via Redis Stream. Heavier rules run there.

Both paths are best-effort. If detection fails (Redis unavailable, panic in a rule, etc.), the request still completes — abuse triage is never on the critical path of your traffic.

What rules look for

The rule set covers a handful of known abuse signatures:

Host phishing. Responses claiming to be a known brand on a tunnel subdomain — for example, a fake login page styled to look like a major SaaS provider.
Credential harvest. POST patterns characteristic of credential-harvesting kits.
Scanner traffic. Tunnels receiving traffic patterns consistent with being targets of internet-wide scanners (informational, not always actionable).
Suspicious content type. Responses with content types inconsistent with legitimate developer use (e.g. executable downloads from a webhook subdomain).
Rate spike. Sudden, sustained traffic spikes that suggest the tunnel is being used as a flood target or amplifier.

The exact rule list and thresholds aren't published — same reason spam filters don't publish theirs.

What happens when a rule fires

Each rule has a configured mode: notify, flag, or enforce. The default is notify. Mode controls what the system does, not whether it detects.

notify. The event is recorded for review. Your tunnel and account are unaffected.
flag. The event is recorded and surfaced to the admin review queue. Your tunnel and account remain operational pending review.
enforce. The system can take action — typically suspending the tunnel and/or the account. Used only for high-confidence rules and well-characterized abuse patterns.

In all modes, the affected request itself is not modified or blocked by the abuse pipeline. Inline detection is observational; enforcement happens at the tunnel/account level, not per-request.

Privacy

Detectors run against request and response data on the proxy path. The async pipeline emits structured events (rule ID, tunnel ID, timestamp, signal evidence) — not full payloads. Payload bodies are not retained in the abuse event store. See the Privacy Policy for the full data-handling description.

What you'll see if your tunnel is affected

If a rule in enforce mode fires against your tunnel:

The tunnel may be terminated. The CLI sees a server-initiated close and surfaces the reason in logs.
Reattach attempts may be rejected — depending on the rule, with a 403 or with a worker close code (worker_suspended, worker_retired).
The dashboard shows the affected tunnel's status.

You do not get a generic "abuse detected" CLI message — JustTunnel does not surface specific rule details to clients, both to avoid signal leakage to actual abusers and because false positives happen.

Appeals and false positives

If you believe your tunnel was suspended in error:

Read the Acceptable Use Policy to confirm the activity was within scope.
Open a support request with:
- The tunnel subdomain or worker name
- A brief description of what the tunnel was being used for
- The approximate time of the suspension

Genuine false positives are reviewed and reversed. Rule thresholds are tuned based on these reports, so accurate descriptions help everyone.

What it doesn't do

A few things abuse detection explicitly does not do:

It does not filter or modify legitimate developer traffic.
It does not block requests in the inline path — the request flows through; enforcement, if any, is async and tunnel-level.
It does not perform deep inspection of encrypted payloads beyond what flows through the proxy as plaintext HTTP.
It is not a substitute for your own application-layer security (auth, CSRF, etc.).

Still stuck?

For abuse-related questions or appeals, contact support with the details listed in Appeals above.