When using Visual Studio Code (VSCode) port forwarding, especially in GitHub Codespaces, Remote SSH, Dev Containers, or WSL setups, there are some practical limitations around bandwidth and HTTP request rate, though most of these are not explicitly documented. Below is a summary of what is known and inferred based on Microsoft documentation, community experiences, and technical behavior of the underlying systems:

🔒 1. HTTP Request Rate Limits

• GitHub Codespaces (uses VSCode port forwarding over a proxy):

  • There is no officially published request-per-second (RPS) limit, but users have reported soft throttling or dropped requests above ~50–100 RPS.

  • Port forwarding is tunneled via a secure reverse proxy, which can introduce latency and rate limiting at higher volumes.

  • Ideal for development, but not for high-frequency testing like load testing or benchmarking.

• Remote-SSH / Dev Containers:

  • Since connections are local or over SSH, you're limited only by:

    • The network bandwidth.

    • Latency and throughput of the SSH connection.

    • Your machine and remote system resources.

  • These are generally not rate-limited, but SSH multiplexing and port forwarding can create bottlenecks if used intensively (e.g., >1000 RPS sustained).

🚀 2. Bandwidth Limitations

• No fixed bandwidth cap, but practical throughput depends on:

  • The host machine and remote system (e.g., Codespace tier).

  • Your network connection if remote.

  • In GitHub Codespaces, outbound bandwidth may be shared across users and is optimized for development, not for serving traffic.

Rough estimates (from community tests in Codespaces):

• Around 10–20 Mbps of sustained throughput is common.

• Latency added by the proxy can be 30–100 ms, depending on region.

⚠️ 3. Not Suitable for High-Frequency APIs

VSCode port forwarding is not designed for production-like API workloads. If you need to test an application with:

• High concurrent request load

• Streaming data

• Real-time communication (WebSockets under high load)

Consider setting up a local reverse proxy (e.g., NGINX) and using a direct network path (such as a public test server or local VM/container), rather than relying on VSCode’s forwarding.

✅ Recommendations

• For normal development (browsing a frontend, sending occasional API requests), VSCode port forwarding is fine.

• For load testing or high-performance profiling, use:

  • A local test environment (e.g., Docker locally).

  • A cloud VM or server with a public IP.

  • Deploy your code to a staging environment, bypassing VSCode's port proxy.