Skip to main content
Debugging a web proxy like Scramjet requires understanding both the proxy internals and how browsers execute proxied code. This guide covers debugging techniques, logging utilities, and common pitfalls.

Logging system

Scramjet includes a custom logging utility in src/log.ts that provides formatted console output with stack traces.

Basic usage

Formatted output

The logger automatically formats messages with:
  • Function name from call stack
  • Severity-based styling (colors, padding)
  • Caller context for debugging

Performance timing

Track execution time for operations:
The time() method categorizes performance:
  • < 1ms: “BLAZINGLY FAST”
  • < 500ms: “decent speed”
  • ≥ 500ms: “really slow”
Performance timing is only active when the rewriterLogs flag is enabled.

Feature flags

Scramjet uses feature flags to control debugging and experimental features.

Available flags

Enabling flags

Site-specific flags

Override flags for specific domains:

Checking flags at runtime

Error handling

Client-side error capture

Scramjet can capture and analyze errors from proxied sites:

Service worker error handling

The service worker catches and logs fetch errors:
Scramjet generates user-friendly error pages:

Stack trace cleaning

Scramjet can clean stack traces to hide proxy internals:

Sourcemap debugging

Sourcemaps allow debugging rewritten code as if it were the original.

Enabling sourcemaps

How sourcemaps work

When enabled, Scramjet injects sourcemap data into rewritten scripts:
The client maintains a sourcemap registry:

Using sourcemaps in DevTools

With sourcemaps enabled:
  1. Open Chrome DevTools
  2. Enable “Enable JavaScript source maps” in Settings
  3. Set breakpoints in the original code
  4. Stack traces show original line numbers
Sourcemaps add overhead to rewriting. Only enable them during development.

Browser DevTools integration

Inspecting service worker

  1. Open chrome://serviceworker-internals/
  2. Find your Scramjet service worker
  3. Click “Inspect” to open dedicated DevTools
  4. View console logs, network requests, and sources

Network inspection

Monitor proxied requests:
  1. Open DevTools → Network tab
  2. Filter by “Fetch/XHR” or “WS” for WebSockets
  3. Inspect request/response headers
  4. Check “Preserve log” to track redirects
Scramjet requests appear as same-origin to DevTools since they’re routed through the service worker.

Console filtering

Filter Scramjet logs:

Common debugging patterns

Tracking URL rewriting

Debugging client hooks

Monitoring rewriter pool

Analyzing performance

Common pitfalls

Forgetting to release rewriters

Incorrect URL metadata

Rewriting before WASM loads

Not handling edge cases

Circular rewriting

Debugging checklist

When encountering issues:
1

Check service worker

Verify the service worker is active:
2

Enable debug flags

Turn on logging:
3

Inspect network

Open DevTools → Network and filter by type (JS, CSS, Fetch/XHR).
4

Check console

Look for Scramjet errors, warnings, or debug messages.
5

Verify transport

Ensure bare-mux transport is configured:
6

Test with simple page

Try proxying a basic HTML page to isolate the issue.

Getting help

If you’re still stuck:
  1. Check GitHub issues: Search for similar problems
  2. Enable all debug flags: Gather comprehensive logs
  3. Create minimal reproduction: Isolate the issue to a small example
  4. Share logs: Include console output, network traces, and error messages
When reporting issues, always include your Scramjet version, browser version, and transport configuration.