firecrawl CLI fails with HTTP 404 through HTTP proxy (bundled axios < 1.16.1, no CONNECT tunneling for HTTPS)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 72/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- node.js, typescript
- Domain
- cli, networking
Research direction
Start by locating the firecrawl SDK dependency declaration in package.json and confirm the exact axios 1.15.2 pin. Update it to at least 1.16.1, then run the documented scrape or search commands with https_proxy enabled. Done means HTTPS requests use proxy tunneling and no longer return the reported 404.
Written by the indexing model from the issue text.
Description
Summary
firecrawl CLI returns Error: Request failed with status code 404 for every scrape / search / map command when run behind an HTTP proxy (e.g. https_proxy=http://127.0.0.1:10808). Root cause: the bundled axios is pinned at 1.15.2, which predates the fix in axios PR #10858 (shipped in axios@1.16.1). Pre-1.16.1 axios does not send a CONNECT request to tunnel HTTPS through an HTTP proxy; instead it forwards the request in forward-proxy style (POST https://api.firecrawl.dev/v2/scrape HTTP/1.1), which many HTTP proxies (xray, squid, etc.) reject.
Environment
firecrawl-cli: 1.19.27 (latest at time of reporting)- firecrawl SDK dep:
axios1.15.2(exact pin, no caret) — verified innode_modules/firecrawl-cli/.../firecrawl/package.jsonand the installedaxios@1.15.2adapter source - Node.js: v24.18.0
- OS: NixOS
- Proxy: xray-core
mixedinbound on127.0.0.1:10808(HTTP + SOCKS5 on the same port)
Reproduction
export https_proxy=http://127.0.0.1:10808
export http_proxy=http://127.0.0.1:10808
firecrawl scrape "https://example.com" --json
# => Error: Request failed with status code 404
firecrawl search "test" --limit 1
# => Error: Request failed with status code 404
Workaround (confirms the proxy is the trigger):
no_proxy="api.firecrawl.dev" firecrawl scrape "https://example.com" --json
# => 200 OK, returns markdown
Expected vs actual
- Expected: axios opens a TLS tunnel through the proxy via
CONNECT api.firecrawl.dev:443, then sends the HTTPS request inside the tunnel. (This is whatcurldoes through the same proxy and it returns 200.) - Actual: axios sends
POST https://api.firecrawl.dev/v2/scrape HTTP/1.1directly to the proxy with the full URL as the request path. xray's mixed inbound has no route matching an HTTPS URL path and returns404 Not Found.
Captured request that axios actually sends to the proxy (plaintext, before TLS):
POST https://api.firecrawl.dev/v2/scrape HTTP/1.1
Host: api.firecrawl.dev
Authorization: Bearer fc-…
Content-Type: application/json
User-Agent: axios/1.15.2
{"url":"https://example.com","formats":["markdown"],"integration":"cli","onlyMainContent":false,"origin":"js-sdk@4.24.0"}
For comparison, curl through the same proxy correctly issues:
CONNECT api.firecrawl.dev:443 HTTP/1.1
and gets 200.
Root cause
This is a long-standing axios bug, not a firecrawl bug. It is tracked in:
- axios#6320 — labeled
issue::security("Axios sends HTTPS data in cleartext to a proxy (regression)") - axios#6330 — "Using HTTP proxy for HTTPS address does not start a HTTP Connection"
- axios#4531, axios#3384 — older duplicates
Fixed by axios PR #10858 (merged 2026-05-06 into v1.x), which integrates https-proxy-agent so axios performs proper CONNECT tunneling for HTTPS targets. The fix first shipped in axios@1.16.1 (2026-05-13), per the axios CHANGELOG.md Security Fixes section.
Code-level confirmation in the installed axios@1.15.2:
lib/adapters/http.jssetsoptions.path = location;(the full target URL) for proxied HTTPS requests- No
https-proxy-agent/HttpsProxyAgent/CONNECTreferences anywhere in the adapter
Suggested fix
Bump the firecrawl SDK's axios dependency from 1.15.2 to >= 1.16.1. The pin is currently exact ("axios": "1.15.2"), so it will not float on a reinstall. After the bump, axios will use CONNECT tunneling for HTTPS through HTTP proxies and the 404 disappears without any user-side workaround.
If a release is not imminent, an alternative is to document no_proxy=api.firecrawl.dev as a workaround in the CLI skill docs (since api.firecrawl.dev is a global CDN and typically does not need to go through a local proxy anyway).
Notes
- This affects any user behind a corporate or local HTTP proxy that expects
CONNECTfor HTTPS (squid, tinyproxy, xray, mitmproxy, etc.), not just xray. - SOCKS5 does not work around it either: setting
https_proxy=socks5h://...makes axios fail withprotocol mismatch, because the bundled axios has no SOCKS support.
- Dominant language
- TypeScript
- Stars
- 635
- Forks
- 106
- Avg merge
- 1h 33m
- Merged PRs (30d)
- 43
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from firecrawl/cli
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
firecrawl-monitor skill: description exceeds Claude Code's 1024-char limit, skill fails to load Open
Difficulty 1/5 Under an hour Newbie friendliness 88/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100