bug: Network Connectivity Problems with HTTPS over HTTP Proxy on Windows (Clash) - AI calls fail, `curl` and specific Node.js agent succeed, Clash logs absent #709

New issue

Closed

opened 2025-10-14 16:10:12 -06:00 by navan · 0 comments

navan commented

2025-10-14 16:10:12 -06:00

Owner

Originally created by @pawaovo on 5/17/2025

I'm experiencing persistent network connectivity issues when using Taskmaster-AI (both via Cursor MCP and CLI) in my Windows environment where an HTTP proxy (Clash, http://127.0.0.1:7897) is required to access external APIs like XAI or OpenAI. AI-driven commands like parse_prd consistently fail with connection timeouts.

Environment:

OS: Windows 11 23H2
Node.js: v20.9.0
Proxy: Clash for Windows , using HTTP proxy mode at http://127.0.0.1:7897.
Taskmaster-AI: Latest version via npx (May 17, 2025)
Shell (for CLI tests): Git Bash / Windows PowerShell

Problem Description:
When Taskmaster-AI attempts to make HTTPS requests to AI service APIs (e.g., api.x.ai:443, api.openai.com:443) through the configured HTTP proxy, the requests fail with connection timeouts (e.g., ETIMEDOUT, ECONNRESET). This occurs even when HTTPS_PROXY and HTTP_PROXY environment variables are correctly set for the Taskmaster-AI MCP service in .cursor/mcp.json or exported in the shell for CLI use. Throughout all failed and successful Node.js tests described below, no relevant connection attempt logs appear in the Clash client's log panel.

Key Debugging Steps and Findings:

curl Test (SUCCESSFUL):
A curl command can successfully access the XAI API through the Clash proxy:

curl -x http://127.0.0.1:7897 https://api.x.ai/v1/chat/completions -H "Authorization: Bearer YOUR_VALID_XAI_API_KEY_PLACEHOLDER" -H "Content-Type: application/json" -d '''{"model": "grok-3-beta", "messages": [{"role": "user", "content": "Hello"}]}'''

This confirms the API key is valid (using a real key for actual test), the proxy is working for curl, and the network path is open.

Node.js CONNECT Test (SUCCESSFUL):
A simple Node.js script (test_connect.js, see attached/linked below) that only performs an HTTP CONNECT request to the proxy for the target api.x.ai:443 succeeds. The proxy returns a 200 OK status, indicating the tunnel can be established.
Clash logs: No entries observed during this test.
Node.js HTTPS Request Test (via HTTPS_PROXY env var - FAILED):
A Node.js script (test_proxy_env.js, see attached/linked - this script relies purely on HTTPS_PROXY env var) attempting a full HTTPS request to api.x.ai fails with ETIMEDOUT (or sometimes ECONNRESET).
Clash logs: No entries observed during this test.
Node.js HTTPS Request Test (with https-proxy-agent - SUCCESSFUL API CALL):
The same Node.js script, when modified to use the https-proxy-agent library to explicitly manage the HTTPS-over-HTTP-proxy connection (test_proxy_hpa.js, see attached/linked), succeeds in connecting to the XAI API and retrieving a valid JSON response.
Clash logs: Surprisingly, still no entries observed in Clash logs even during this successful API call via the Node.js script and https-proxy-agent. This is perplexing but the API call itself does succeed.
Taskmaster-AI Code Insight:
Taskmaster-AI's codebase includes import https from 'https';, suggesting it likely uses Node.js's built-in https module for requests. This would explain why it exhibits the same proxying issues as test case #3 (failure when relying on HTTPS_PROXY env var alone).

Conclusion & Suggestion:
The evidence strongly suggests that Node.js's default mechanism for handling HTTPS requests via an HTTP proxy (using the HTTPS_PROXY environment variable) is problematic or incompatible in this specific Windows + Clash + Node.js v20.9.0 environment. However, when a dedicated library like https-proxy-agent is used within a Node.js script, the API call succeeds, even if Clash logging behavior remains unusual.

Given that Taskmaster-AI relies on the built-in https module, it's highly susceptible to these same issues. The absence of Clash logs across all Node.js tests (successful or not) is an additional confounding factor that might point to deeper issues in how Node.js interacts with the network stack or this specific proxy on Windows, but the success with https-proxy-agent shows a viable path for Node.js applications.

Could the Taskmaster-AI team please consider enhancing the tool's network request logic to use a more robust HTTPS proxy handling mechanism, such as integrating https-proxy-agent or a similar library, when an HTTP/HTTPS proxy environment is detected? This would likely improve compatibility and reliability for users in environments requiring HTTP proxies, even if underlying system/proxy logging behaviors are inconsistent.

Thank you for your time and this fantastic tool! Please let me know if any further information or testing from my end would be helpful.

Links to Test Scripts (Gist/Pastebin):
test_connect.json
test_proxy.json

*Originally created by @pawaovo on 5/17/2025* I'm experiencing persistent network connectivity issues when using Taskmaster-AI (both via Cursor MCP and CLI) in my Windows environment where an HTTP proxy (Clash, `http://127.0.0.1:7897`) is required to access external APIs like XAI or OpenAI. AI-driven commands like `parse_prd` consistently fail with connection timeouts. **Environment:** * **OS:** Windows 11 23H2 * **Node.js:** v20.9.0 * **Proxy:** Clash for Windows , using HTTP proxy mode at `http://127.0.0.1:7897`. * **Taskmaster-AI:** Latest version via `npx` (May 17, 2025) * **Shell (for CLI tests):** Git Bash / Windows PowerShell **Problem Description:** When Taskmaster-AI attempts to make HTTPS requests to AI service APIs (e.g., `api.x.ai:443`, `api.openai.com:443`) through the configured HTTP proxy, the requests fail with connection timeouts (e.g., `ETIMEDOUT`, `ECONNRESET`). This occurs even when `HTTPS_PROXY` and `HTTP_PROXY` environment variables are correctly set for the Taskmaster-AI MCP service in `.cursor/mcp.json` or exported in the shell for CLI use. **Throughout all failed and successful Node.js tests described below, no relevant connection attempt logs appear in the Clash client's log panel.** **Key Debugging Steps and Findings:** 1. **`curl` Test (SUCCESSFUL):** A `curl` command can successfully access the XAI API through the Clash proxy: ```bash curl -x http://127.0.0.1:7897 https://api.x.ai/v1/chat/completions -H "Authorization: Bearer YOUR_VALID_XAI_API_KEY_PLACEHOLDER" -H "Content-Type: application/json" -d '''{"model": "grok-3-beta", "messages": [{"role": "user", "content": "Hello"}]}''' ``` This confirms the API key is valid (using a real key for actual test), the proxy is working for `curl`, and the network path is open. 2. **Node.js `CONNECT` Test (SUCCESSFUL):** A simple Node.js script (`test_connect.js`, see attached/linked below) that only performs an HTTP `CONNECT` request to the proxy for the target `api.x.ai:443` **succeeds**. The proxy returns a `200 OK` status, indicating the tunnel can be established. *Clash logs: No entries observed during this test.* 3. **Node.js HTTPS Request Test (via `HTTPS_PROXY` env var - FAILED):** A Node.js script (`test_proxy_env.js`, see attached/linked - this script relies purely on `HTTPS_PROXY` env var) attempting a full HTTPS request to `api.x.ai` **fails** with `ETIMEDOUT` (or sometimes `ECONNRESET`). *Clash logs: No entries observed during this test.* 4. **Node.js HTTPS Request Test (with `https-proxy-agent` - SUCCESSFUL API CALL):** The same Node.js script, when modified to use the `https-proxy-agent` library to explicitly manage the HTTPS-over-HTTP-proxy connection (`test_proxy_hpa.js`, see attached/linked), **succeeds** in connecting to the XAI API and retrieving a valid JSON response. *Clash logs: Surprisingly, still no entries observed in Clash logs even during this successful API call via the Node.js script and `https-proxy-agent`.* This is perplexing but the API call itself *does* succeed. 5. **Taskmaster-AI Code Insight:** Taskmaster-AI's codebase includes `import https from 'https';`, suggesting it likely uses Node.js's built-in `https` module for requests. This would explain why it exhibits the same proxying issues as test case #3 (failure when relying on `HTTPS_PROXY` env var alone). **Conclusion & Suggestion:** The evidence strongly suggests that Node.js's default mechanism for handling HTTPS requests via an HTTP proxy (using the `HTTPS_PROXY` environment variable) is problematic or incompatible in this specific Windows + Clash + Node.js v20.9.0 environment. However, when a dedicated library like `https-proxy-agent` is used within a Node.js script, the API call succeeds, even if Clash logging behavior remains unusual. Given that Taskmaster-AI relies on the built-in `https` module, it's highly susceptible to these same issues. The absence of Clash logs across all Node.js tests (successful or not) is an additional confounding factor that might point to deeper issues in how Node.js interacts with the network stack or this specific proxy on Windows, but the success with `https-proxy-agent` shows a viable path for Node.js applications. **Could the Taskmaster-AI team please consider enhancing the tool's network request logic to use a more robust HTTPS proxy handling mechanism, such as integrating `https-proxy-agent` or a similar library, when an HTTP/HTTPS proxy environment is detected?** This would likely improve compatibility and reliability for users in environments requiring HTTP proxies, even if underlying system/proxy logging behaviors are inconsistent. Thank you for your time and this fantastic tool! Please let me know if any further information or testing from my end would be helpful. **Links to Test Scripts (Gist/Pastebin):** [test_connect.json](https://github.com/user-attachments/files/20265842/test_connect.json) [test_proxy.json](https://github.com/user-attachments/files/20265843/test_proxy.json)