Model Proxy Login Failures as Correlated Events, Not One Status Code

#privacy

A 403, challenge, or failed login does not tell you which layer failed.

For an authorized workflow, the useful model is a join across three event families:

proxy transport — gateway, DNS, tunnel, TLS, exit and latency;
identity/application — test account, authentication method and expected step;
security outcome — event type, authentication status and risk context.

Cloudflare added an Account Abuse Protection Events dataset to Logpush on August 20, 2026. Its fields include authentication provider/method/status, bot score, ASN and geography, client IP, ephemeral ID, fraud-email risk, JA4, request ID, timestamp, user agent and account-related identifiers.

That is a useful correlation surface, but only if you resist turning a score into a verdict.

Define a minimized event model

Here is a provider-neutral shape for a diagnostic record:

type DiagnosticEvent = {
  correlationId: string;
  observedAt: string;

  route: {
    gatewayReached: boolean;
    tunnelEstablished: boolean;
    tlsEstablished: boolean;
    addressFamily: "ipv4" | "ipv6" | "unknown";
    dnsMode: "local" | "remote" | "unknown";
    region: string;
    sessionRef: string; // scoped pseudonym, never a credential
    latencyMs?: number;
  };

  identity: {
    accountRef: string; // scoped pseudonym
    authMethod: string;
    authProvider: string;
    expectedStep: string;
  };

  security?: {
    eventType: string;
    authStatus: string;
    botScoreBand?: "low" | "medium" | "high";
    fraudRiskBand?: "low" | "medium" | "high";
    asn?: number;
    country?: string;
    ja4Changed?: boolean;
  };

  application: {
    httpStatus?: number;
    expectedOutcome: boolean;
  };
};

Notice what is missing: passwords, cookies, one-time codes, full email addresses, raw tokens and request bodies.

Normalize before joining

Do not copy a provider event wholesale into the developer-facing dataset. Derive the minimum fields you need.

function band(score?: number) {
  if (score == null) return undefined;
  if (score < 30) return "low";
  if (score < 70) return "medium";
  return "high";
}

function minimize(raw: ProviderAccountEvent) {
  return {
    correlationId: raw.requestId,
    observedAt: raw.timestamp,
    eventType: raw.eventType,
    authStatus: raw.authenticationStatus,
    botScoreBand: band(raw.botScore),
    fraudRiskBand: band(raw.fraudEmailRisk),
    asn: raw.clientAsn,
    country: raw.clientCountry,
    ja4: raw.ja4,
  };
}

Choose band thresholds with the system owner; the numbers above are placeholders, not provider guidance.

If the source contains direct identifiers, transform or exclude them before the routine analysis table. An ephemeral ID is not necessarily anonymous if another dataset can link it back to a person or session.

Classify with evidence, not guesses

A simple classifier can enforce better language in incident reports:

function classify(e: DiagnosticEvent) {
  if (!e.route.gatewayReached || !e.route.tunnelEstablished) {
    return "transport_failure";
  }
  if (!e.route.tlsEstablished) {
    return "tls_or_destination_failure";
  }
  if (e.security?.authStatus === "failed") {
    return "authentication_or_policy_failure";
  }
  if (!e.application.expectedOutcome) {
    return "application_outcome_mismatch";
  }
  return "success";
}

This does not automate blame. It selects the next evidence set to inspect.

Run a controlled matrix

Keep these constant:

one authorized test account in a known state;
one client build, user agent and TLS stack;
one documented authentication method;
fixed pacing and concurrency one;
one approved region at a time.

Change one route variable, repeat with the same proxy session, and compare against a known-good control only when permitted. Do not spray retries across accounts and exits. Besides being difficult to interpret, that behavior can create the exact risk signals under investigation.

Useful interpretations

No security event + tunnel failure: start with the gateway, DNS and TLS path.
Transport success + authentication-method mismatch: fix the identity flow; do not rotate IPs.
JA4 changes after a client upgrade: inspect the client and tunnel path; do not spoof a fingerprint to evade controls.
Risk bands rise after rapid retries: stop, review retry budgets and preserve the event sequence.
Only the controlled route changes: inspect ASN, geography, address family and session stability, then repeat.

Operational checklist

Use one harmless correlation ID across client, proxy and owner-controlled edge logs.
Store route health and account outcome in separate fields.
Hash or pseudonymize stable identifiers with a scoped key.
Restrict raw events and log exports.
Set short diagnostic retention.
Define stop conditions for challenge spikes and account lockouts.
Report uncertainty instead of converting one score into “bad proxy.”

I work with 98IP, and this post is a disclosed technical perspective. Our English proxy-testing resources are available at https://en.98ip.com/?k=dev

Use the method only on systems and accounts you own or are authorized to test. It is for observability and diagnosis—not bypassing account protection, fingerprint spoofing, or evading security decisions.

DEV Community