Skip to main content
Rockxy captures every HTTP and HTTPS request flowing through your Mac by running a local proxy server on port 9090. Point any app at the proxy — or let Rockxy configure the system proxy automatically — and watch requests stream in real time.
Traffic capture list view

Traffic list showing captured HTTP/HTTPS requests with method, host, status, and timing columns

​
How It Works

Rockxy runs a SwiftNIO-based proxy server that accepts HTTP and HTTPS CONNECT requests on localhost:9090. When you start capturing, Rockxy can automatically configure the macOS system proxy settings so all HTTP/HTTPS traffic from every application routes through the proxy. The proxy intercepts each request, records the full request and response (headers, body, timing), and forwards traffic to the destination server. For HTTPS, Rockxy performs a man-in-the-middle interception using a locally generated root CA — see HTTPS Interception for details.
Rockxy automatically sets and restores the macOS system HTTP/HTTPS proxy when you start and stop capture. Your original proxy settings are preserved and restored on exit, even if Rockxy crashes.

​
Starting and Stopping

Use the toolbar controls or keyboard shortcuts to manage capture state: When recording is paused, the proxy stays active (so apps don’t lose connectivity) but new requests are not added to the traffic list.

​
Request List

The main traffic list displays captured requests in a high-performance virtualized table (backed by NSTableView) that handles 100,000+ rows without slowing down. Each row shows:
  • Method — color-coded badge (GET, POST, PUT, DELETE, PATCH, etc.)
  • Host — the destination hostname
  • Path — the request path and query string
  • Status — HTTP status code with color coding (2xx green, 3xx blue, 4xx orange, 5xx red)
  • Size — combined request + response body size
  • Duration — total round-trip time in milliseconds
  • Content Type — detected response type (JSON, XML, HTML, image, etc.)
Above the request list, tabbed views give you different perspectives on your captured data:
  • Traffic — the full chronological request list
  • Logs — application log entries correlated with network activity
  • Timeline — visual waterfall showing request sequences and dependencies
  • Errors — automatically grouped errors from both network and log sources
  • Performance — latency analysis, slow request detection, payload size tracking

​
Filtering Traffic

The filter bar at the top of the request list supports multiple simultaneous filters to narrow down traffic:
  • Search — free-text search across URL, headers, and body content
  • Method — filter by HTTP method (GET, POST, PUT, DELETE, etc.)
  • Status Code — filter by status code range (2xx, 3xx, 4xx, 5xx) or specific code
  • Content Type — filter by response type (JSON, XML, HTML, Image, etc.)
  • Domain — filter to a specific hostname or domain pattern
Combine multiple filters to isolate exactly the traffic you need. For example, filter to POST requests returning 5xx status codes on api.example.com to find failing API calls instantly.

​
Request Inspector

Select any request in the traffic list to open the inspector panel on the right. The inspector provides tabbed views into every aspect of the request:

​
Headers

Displays request and response headers in a searchable key-value table. Request headers appear at the top, response headers below, each with their own section.

​
Body

Auto-detects the content type and renders the body accordingly:
  • JSON — collapsible tree view with syntax highlighting
  • XML/HTML — formatted tree view with tag folding
  • Images — inline preview (PNG, JPEG, GIF, WebP, SVG)
  • Binary — hex dump with ASCII sidebar
  • Text — raw text with line numbers

​
Cookies

Shows request cookies (sent via Cookie header) and response cookies (from Set-Cookie headers) with parsed attributes: domain, path, expiry, secure, httpOnly, sameSite.

​
Timing

Visual waterfall bar breaking down the request lifecycle:
  • DNS Lookup — domain resolution time
  • Connect — TCP connection establishment
  • TLS Handshake — SSL/TLS negotiation (HTTPS only)
  • Time to First Byte (TTFB) — server processing time
  • Transfer — response body download time

​
Raw

Full HTTP/1.1 text dump of the request and response, exactly as sent/received on the wire. Useful for debugging protocol-level issues.

​
Certificates

For HTTPS requests, displays the full certificate chain from the remote server. See HTTPS Interception for more on certificate handling.

​
WebSocket

For WebSocket connections, shows the frame list after the HTTP upgrade. See WebSocket Inspection for details.

​
GraphQL

For detected GraphQL requests, shows the parsed operation with query text and variables. See GraphQL Support for details.

​
Session Management

Rockxy stores active traffic in a high-performance in-memory ring buffer with a capacity of 50,000 transactions. When the buffer fills up, the oldest 10% of entries are either moved to SQLite storage or discarded. Completed sessions are persisted to a local SQLite database, so you can quit and relaunch Rockxy without losing your captured data. Response bodies larger than 1 MB are stored as separate files on disk to keep the database lean.
When the ring buffer reaches capacity, the oldest entries are evicted automatically. If you need to preserve specific requests, export them before the buffer fills. Use Cmd + K to manually clear the session and free memory.

​
Supported Protocols

​
Allow List

When you only care about traffic from a specific set of services, enable the Allow List to record only matching requests. Traffic that doesn’t match is still proxied (forwarded transparently to the destination), it just isn’t shown in the request list or saved to the session. Open the Allow List window via Tools > Allow List… (Cmd+Opt+A) or right-click any captured request > Tools > Allow List… to create a pre-filled rule from that request.

​
Rule fields

  • Name — free-form label shown in the rule table. Leave blank to use the pattern as the name.
  • Matching Rule — the URL pattern to match against. Supports wildcard (*, ?) or regex.
  • Method — HTTP method filter (ANY, GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, TRACE).
  • Match Type — Use Wildcard escapes the pattern and treats * as any characters and ? as a single character. Use Regex passes the pattern through to NSRegularExpression unchanged.
  • Include all subpaths of this URL — wildcard-only toggle. When enabled, the pattern is anchored to allow any trailing path, query, or fragment.
New user-authored regex rules are case-sensitive by default. To match a pattern case-insensitively, prepend (?i) to your regex (e.g., (?i)^https://api\.example\.com/.*$).

​
Creating a rule from a captured request

Right-click any request in the traffic list, then choose Tools > Allow List…. The editor sheet opens pre-filled with:
  • A wildcard pattern based on the request’s host and path (e.g., *api.github.com/repos/owner/repo/issues*)
  • The request’s HTTP method
  • A suggested name that references the request
Edit any field before saving. The new rule is added and immediately selected in the rule list.

​
Quick-create from the sidebar

Right-click any domain in the sidebar, then choose Tools > Create Allow List Rule…. The editor sheet opens pre-filled with a wildcard pattern for that domain (e.g., *api.stripe.com/*) and method ANY.

​
Managing rules

The Allow List window mirrors the Block List and Breakpoint Rules windows:
  • Enable Allow List Tool toggle at the top activates or deactivates the entire filter. While inactive, all traffic is recorded as usual.
  • Filter button in the bottom bar reveals a filter bar that narrows the visible rules by Name, Method, or Matching Rule column.
  • More menu at the bottom exposes New / Edit / Duplicate / Enable / Export Settings / Import Settings / Delete.
  • Import Settings accepts exports from earlier versions (host-only schema) and auto-migrates them into anchored regex rules that preserve the old matching semantics exactly.

​
Legacy migration

If you have an existing allow-list.json from before the redesign, it is loaded automatically on first launch and converted to the new rule format. The original file is preserved as allow-list.legacy.json in the same directory for recovery. Migrated entries:
  • Exact host example.com becomes an anchored regex that matches only example.com (with any scheme, port, path, query, or fragment) — never substring hosts like notexample.com or subdomains like api.example.com.
  • Subdomain wildcard *.example.com becomes an anchored regex that matches subdomains only (api.example.com, a.b.example.com) — never the bare root example.com and never substring hosts.
Migrated legacy entries preserve legacy case-insensitive host matching via an inline (?i) flag at the start of the generated regex. This applies to both migrated exact-host entries like example.com and migrated subdomain wildcard entries like *.example.com, so https://EXAMPLE.com/path and https://API.example.com/path still match their migrated rules.Newly authored regex rules are case-sensitive by default. If you need case-insensitive matching on a new rule, add an inline flag to your pattern, e.g. (?i)^https://api\.example\.com/.*$.

​
Sessions and Export

Save your captured traffic for later analysis or sharing.
  • Save Session — File > Save Session… (Cmd+Shift+S) saves a native .rockxysession file with full metadata.
  • Export HAR — File > Export HAR… (Cmd+Shift+E) writes the industry-standard HAR format for cross-tool compatibility.
  • Import HAR — File > Import HAR… (Cmd+Shift+I) loads a HAR file into the traffic list.
  • Open Session — File > Open Session… (Cmd+O) restores a previously saved .rockxysession file.
  • Copy as cURL — right-click any request > Copy as cURL for a ready-to-run command.
See Sessions & HAR for full details on save/export workflows.

​
Next Steps

HTTPS Interception

Set up certificate trust to inspect encrypted HTTPS traffic

WebSocket Inspection

Capture and inspect WebSocket frames in real time

GraphQL Detection

Automatic GraphQL-over-HTTP operation detection and inspection

Traffic Rules

Block, redirect, throttle, or modify requests with rules