HTTP/3 (QUIC) scanning

HTTP/3 is the third major version of HTTP. Unlike HTTP/1.x and HTTP/2, which run over TCP + TLS, HTTP/3 runs over QUIC — a UDP-based transport with built-in encryption and multiplexing. Many sites still answer on HTTP/1.1 or HTTP/2 over TCP and advertise HTTP/3 separately (often via an Alt-Svc response header).

Nikto Platform can run Nikto, LFIC, and Bustah scans over HTTP/3 when you opt in.

What the platform does

HTTP/3 is a shared scan option, not a crawler feature. Any tool that sends requests through the platform's own HTTP client can ride QUIC; the headless/Standard crawler cannot.

Tool	HTTP/3
Nikto	Yes — checkbox on the Nikto Options tab. First HTTPS contact also probes which protocols the host speaks.
LFIC	Yes — same HTTP client. No checkbox on the LFIC form; set Force HTTP/3 on project or host Scan Defaults, or it inherits that default when left unset.
Bustah	Yes — same as LFIC. Sweeps honor HTTP Version from Scan Defaults.
Crawl	No. Headless uses Chromium (TCP). Standard is a browser-free HTTP crawler, not QUIC.

• Default is HTTP/1.1. A scan does not silently upgrade to HTTP/2 or HTTP/3 just because the target supports them. Evidence stays on the protocol you actually used — predictable for triage and reports.
• Explicit opt-in. Check HTTP/3 (QUIC) — proxy not supported on the Nikto tab, or set HTTP Version → Force HTTP/3 in Scan Defaults for Nikto / LFIC / Bustah.
• Transport. Outbound HTTP/3 uses UDP to the target (usually port 443 on HTTPS hosts).

Enabling HTTP/3 on a scan

Nikto (wizard or host Nikto tab → New Scan):

1. On the Nikto tab, expand Options.
2. Check HTTP/3 (QUIC) — proxy not supported.
3. Clear any Proxy on the Throttling & Limits tab — QUIC cannot be routed through an HTTP proxy.

LFIC and Bustah: there is no per-scan HTTP/3 checkbox. Use Project Settings → Scan Defaults → HTTP Version → Force HTTP/3 (or the same field on the host Scan Defaults tab). That default applies to new LFIC and Bustah scans the same way it does for Nikto. A value set on the Nikto tab in a multi-tool launch applies to Nikto only.

If the project has an enforced proxy, checking HTTP/3 opens a confirmation:

HTTP/3 bypasses the enforced proxy

This project enforces a proxy. HTTP/3 (QUIC) cannot route through it. Enabling HTTP/3 means scan traffic will not use the proxy.

You must click Bypass proxy & use HTTP/3 to proceed. This is intentional: QUIC and classic HTTP proxies are incompatible, and the platform will not silently skip your proxy requirement.

When HTTP/3 is chosen automatically

On the first HTTPS Nikto contact with a host, the scanner probes which protocols the target speaks (TCP/TLS for HTTP/1.1 and HTTP/2, UDP/QUIC for HTTP/3). Results are saved as host intel under Protocols (for example HTTP/1.1, HTTP/2, HTTP/3) on the host Overview tab. LFIC and Bustah do not run this probe — they only use HTTP/3 when HTTP Version is set (Scan Defaults or an inherited force).

Situation	Behavior
You checked HTTP/3	Always HTTP/3 for that scan.
You did not check HTTP/3, target speaks HTTP/1.1 and/or HTTP/2	Stays on HTTP/1.1 (default).
Target is HTTP/3-only (QUIC works, TCP HTTP does not), no proxy in force	Scan auto-uses HTTP/3 so the host is reachable.
Target is HTTP/3-only, but a proxy is configured (scan or enforced)	Scan fails with an info finding: Scan failed: HTTP/3-only host cannot use the configured proxy. Enable HTTP/3 explicitly (which bypasses the proxy) to scan it.

Discovering HTTP/3 via Alt-Svc

A normal HTTP/1.1 Nikto run may produce an Alt-Svc info finding when the server advertises HTTP/3, for example:

Alt-Svc header advertises: h3=":443". … Re-run this scan with the HTTP/3 option enabled to test the target over QUIC.

That is your cue to re-launch with HTTP/3 (QUIC) checked.

Deployment requirements (QUIC egress)

HTTP/3 needs outbound UDP from the scanner to the target (typically UDP/443). Many Docker and cloud environments allow TCP scanning but block or mishandle QUIC egress.

The API learns whether QUIC egress appears usable during operation. If the environment cannot complete QUIC handshakes, HTTP/3 scans may fail at request time with a clear error rather than hanging indefinitely.

Status page

Open Status in the sidebar (or visit /nikto-diag on the API) for build/runtime diagnostics, storage sizes, and a live app-log tail. The HTTP/3 (QUIC) section shows observed QUIC egress status and a test form (public hosts only). See Status and diagnostics.

Limitations

• No HTTP proxy — HTTP/3 cannot use the scan proxy or an enforced project proxy unless you explicitly bypass the proxy (see above).
• Raw HTTP/1.x probes — Some low-level Nikto probes send verbatim HTTP/1.x wire format. Those are skipped on a forced HTTP/3 scan (they cannot ride QUIC).
• Not the crawler — Crawl engines never speak QUIC. Use Nikto, LFIC, or Bustah to test HTTP/3.
• Independent of Force IPv6 — IPv6 targeting and HTTP/3 are separate options. You can use either, both, or neither.

How HTTP/3 appears in findings

Each finding stores the negotiated protocol on the request/response (for example HTTP/3.0). Open finding detail to inspect traffic.

Reconstructed views (not raw wire bytes)

HTTP/3 does not have a human-readable request line or Host: header on the wire — headers are compressed with QPACK inside QUIC frames. The UI therefore shows reconstructed request/response text, not a literal packet dump.

Above the request/response panes:

Reconstructed views below — HTTP/3.0 uses binary framing (QUIC/QPACK).

Toggle between two honest representations:

View	What you see
H3 Pseudo Headers (default)	Native HTTP/3 logical framing: :method, :scheme, :authority, :path, then lowercased field names. Response uses :status instead of an HTTP/1.1 200 line.
HTTP/1.1 Style	Familiar GET https://… request line and HTTP/3.0 200 status line with Title-Case headers — easier if you think in HTTP/1.x terms.

The same toggle applies to HTTP/2 findings (HPACK instead of QPACK).

Copy as Curl in finding detail adds --http3 when the stored protocol is HTTP/3 (your local curl must be built with HTTP/3/QUIC support for replay to work).

How HTTP/3 appears in reports

When you add a finding to the Report, HTTP request/response evidence is snapshotted at add time.

• Evidence labels include the protocol for HTTP/2 and HTTP/3, for example GET https://example.com/ [HTTP/3.0] — so readers know the block below is a reconstruction, not a classic HTTP/1.x transcript.
• HTML, Markdown, and JSON exports use the same pseudo-header framing as the default finding-detail view for HTTP/3 (and HTTP/2) evidence.

LFI Commander file evidence in reports is unchanged — only HTTP-based scan findings carry protocol framing.

Next steps

• Scan options — HTTP/3 checkbox and proxy bypass
• Triage findings
• Build and export a report

Further reading

Topic	Link
HTTP/3	RFC 9114
QUIC transport	RFC 9000
QUIC TLS	RFC 9001
QUIC loss recovery & congestion	RFC 9002
QPACK (HTTP/3 header compression)	RFC 9204
Alt-Svc header	MDN: Alt-Svc
HTTP/3 overview	MDN: HTTP/3
QUIC implementation used	quic-go