After wasting hours to try and fix REST API websocket hangups and CORS errors despite using Express and Vite server proxy, I have come to conclusion that Bolt.diy just isnt ready yet for proper development.
Something in the webcontainer is prohibiting server-side API connections and I tried multiple approaches. Regular CORS errors and no access-control-allow-origin, socket hang ups despite vite and express servers running on separate terminals or middleware proxy approach. Bolt.new seems to handle this flawlessly, Bolt.diy just doesnt seem to be ripe enough yet to handle these kind of configurations and makes no more fun when multiple proxy paths always fail. Hopefully the devs can solve these configuration issues sometime.
thanks for the feedback.
Can you provide a example application export/chat where all these errors can be seen? Otherwise its hard to get this fixed by the devs without a reproduceable problem.
Thanks for your quick reply, I can provide a terminal and dev console error if it helps.
thanks, better than nothing, but if someone should take a look at this, it would be better to have a complety bolt.diy project to see the errors themself and have the possibilitty to analyse and fix it based of this.
If they need to build the usecases etc. themself, it take much longer, if even someone wants to do this effort now.
Thanks I dont need it fixed, I got it fixed in Bolt.new. 
It’s just a general Feedback about the webcontainer isolation within Bolt.diy and restrictions that are in place, preventing easy access to external API connections compared to Bolt.new. Hope it helps as a general guideline.
Conclusion: The core problem remains the same; a backend js-server running inside the WebContainer, cannot successfully fetch data from external APIs. The connection is being reset (ECONNRESET / “socket hang up”). This is likely due to network limitations of the WebContainer environment or the API potentially blocking requests from this type of environment.
The problem isn’t with the code structure or missing dependencies. The persistent ECONNRESET error indicates that backend proxies cannot reach externel APIs from within the WebContainer environment, like Bolt.new can.
The headers look reasonable (Origin, Referer, Cookie are removed before sending), but the connection is still being dropped by the target server.
This type of error, especially after ruling out common header issues, often points to deeper connection problems like:
- TLS/SSL Handshake Issues: The Node.js environment within WebContainer might have trouble negotiating a secure connection with target servers.
- Server-Side Blocking: The target API might be actively blocking requests originating from the IP range or specific characteristics of the WebContainer environment.
- Connection Handling: How
http-proxy-middleware manages connections might be incompatible with target server’s expectations.
The issue might be related to TLS/SSL negotiation or potentially the target server actively refusing connections from this environment (perhaps due to IP blocking, WAF rules, or specific header/TLS requirements).
Cloudflare might be the solution
