Support FAQ

MTU and Path Fingerprinting

MTU and path fingerprinting looks at evidence created by the route between a client and an application. It is part of network fingerprinting, but it answers a narrower question: what does the path tell us about the connection?

MTU stands for maximum transmission unit. In practice, MTU-related evidence and nearby TCP signals can suggest whether traffic is travelling through a mobile network, VPN, tunnel, corporate gateway, residential proxy, or ordinary direct path. Peakhour's MTU fingerprinting analysis covers the defensive motivation in more depth.

What path evidence can show

Path evidence can include TCP fingerprinting signals, packet-size constraints, connection behaviour, timing, network route, ASN, geography, proxy classification, and whether the observed path matches the claimed client or account history. It is most useful when compared with higher-layer evidence such as TLS fingerprinting, JA4 fingerprinting, HTTP behaviour, and headers.

For example, traffic may claim to be a normal browser but arrive through a path commonly associated with automation, proxy networks, or mobile carrier aggregation. That does not make the request malicious. It does mean the request may deserve a different threshold, challenge, log level, or review path.

How teams use MTU and path fingerprints

MTU and path evidence is useful for residential proxy detection, bot analysis, account protection, and rate controls. It can help separate:

  1. ordinary browser traffic from automated clients moving through unusual paths;
  2. mobile users from suspicious mobile-proxy patterns;
  3. VPN or tunnel paths from expected residential or corporate routes;
  4. one distributed bot run from unrelated users sharing a carrier-grade NAT;
  5. ambiguous traffic that should be logged from high-confidence traffic that can be challenged or limited.

This evidence is also useful during incident review. If a scraping run, credential attack, or Layer 7 pressure event rotates IP addresses but keeps similar path and client signals, responders can group those requests more effectively than they could with IP addresses alone.

What are the limits?

Path evidence is context, not identity. Mobile networks, privacy tools, corporate gateways, satellite networks, and international routing changes can all produce unusual signals for legitimate users. MTU and path observations can also shift as networks change.

Do not use one path signal as a final decision. Combine it with route sensitivity, request behaviour, session history, IP intelligence, browser consistency, and policy outcome. If the evidence is weak, log it. If it lines up with abusive behaviour, use a proportionate control such as bot management, rate limiting, challenge, or review.

Related Articles

AI Crawler User Agents

A practical reference for common AI crawler user agents, operators, purposes, and recommended Peakhour bot-management actions.

AI For Cybersecurity

AI For Cybersecurity explains the concept in the context of AI security, with practical checks and mitigation considerations for site operators.

AI Image Generation

AI Image Generation explains the concept in the context of AI security, with practical checks and mitigation considerations for site operators.

AI Misuse

AI Misuse explains the concept in the context of AI security, with practical checks and mitigation considerations for site operators.

© PEAKHOUR.IO PTY LTD 2025   ABN 76 619 930 826    All rights reserved.