Routing Edge TTS separately from STranslate

Summary

I deployed an Edge TTS API on Cloudflare Workers and connected it to STranslate. Direct HTTP requests generated valid MP3 files, but STranslate could not play any audio.

The TTS service was healthy. The failure came from an application-wide network rule that forced every request from STranslate.exe to connect directly, even though the TTS endpoint needed to use a proxy.

Impact

Translation in STranslate continued to work, but speech synthesis through the Edge TTS plugin did not.

What I was building

I wanted a speech output capability that a future agent could use. Hermes is not deployed yet, so the immediate use case was allowing STranslate to call my own text-to-speech service.

Microsoft Edge TTS offered free speech synthesis, and the service only needed to expose an API that forwarded requests rather than run a model itself. Cloudflare Workers was a better fit for this occasional workload than keeping a server running continuously.

I deployed a GitHub project to Cloudflare Workers and received an API endpoint that returned MP3 files over HTTP. A test with curl successfully generated audio, confirming that the endpoint, audio format, and Worker deployment were working.

Investigation

After adding the API endpoint to STranslate’s Edge TTS plugin, audio playback failed.

I first suspected the TTS service, but direct requests continued to succeed. STranslate’s logs then showed incomplete requests, connection timeouts, and SSL connection errors.

While checking the network configuration, I found a rule I had previously added to keep translation working:

STranslate.exe → direct connection

That rule caused every request from STranslate to bypass the proxy. This was a problem because STranslate was accessing two kinds of service with different network requirements:

• the translation service could be reached directly;
• the TTS service needed to go through the proxy.

The rules were grouped by application, so these different requirements had been tied together.

Resolution

I kept the direct-connection rule for STranslate and added a more specific rule that routed the TTS service address through the proxy.

After that change, both translation and TTS audio worked normally.

What I learned

One application does not necessarily have only one network requirement. Routing rules should account for the destination, not just the process making the request.

When debugging an API integration, it also helps to test each boundary separately:

• whether the service itself is healthy;
• whether the client sends the request;
• whether the network path is reachable;
• whether the client can handle the response.

Follow-up

This TTS service can become a speech output module for a future agent:

text response → TTS request → audio playback