split tunneling dictation fix: keep voice working while the VPN stays on

Certain rituals come with working on the road and one of them is absurdly consistent: you connect to a VPN for safety, open ChatGPT to take notes, press the microphone, and nothing arrives. Typing still works, pages load instantly, and the same setup at home without the VPN would dictate without complaint. The divergence, text fine and voice dead, is the fingerprint of a proxying traffic path rather than a configuration problem, and the remedy is one of the most elegant in this troubleshooting series: a split tunneling dictation fix. Instead of moving your whole connection in and out of the tunnel, you move only the speech traffic, the one thing the proxy is choking.

The traveler's case deserves the name because the pattern recurs in every hotel and every client office. Hotel Wi-Fi is usually slow and sometimes filtered; the VPN adds encryption and a distant exit node on top; and browser speech recognition, which streams audio to a recognizer and expects a responsive answer, collapses under the added hop. Nothing crashes, nothing errors visibly, the button just yields silence or spins. Since the typing path is text, small, and retry-tolerant, it sails through the same connection that is suffocating the audio, which is why the failure is so easy to misread as a microphone problem.

The split-tunneling approach keeps the protection you actually care about: your general traffic stays inside the VPN, and only the domain whose audio streams need a clean route goes around it. That single exception, scoped by hostname or by app, restores dictation in minutes without leaving your other traffic unprotected. This article explains why proxies hurt speech specifically, walks through configuring the split on the three most common VPN clients, summarizes field measurements of latency and reliability, and ends with a travel routine you can run before you even open the laptop. The routine is short because the fix is small: a scoped exception, a restart, a test sentence, and the voice is back.

Text requests are small and patient. A typed prompt is a few kilobytes, the server answers when the answer is ready, and if packets dribble in at a modest rate the page simply renders a little later. Nothing about the experience depends on timing precision. Speech, by contrast, is a live stream: the browser captures a buffer, forwards it over WebSocket or fetch to the recognition endpoint, and waits for interim results that are supposed to arrive while you are still talking. The interaction is conversational, and it needs latency measured in tens of milliseconds to feel natural, with packet loss tolerated only in small amounts.

A VPN adds two penalties that hit exactly those requirements. First, bandwidth: the proxy encrypts and relays your audio through another server that is often in another country, adding a leg of geographical travel, and hotel or office networks already run near saturation, so the added load pushes the stream over the cliff. Second, behavior: networks not built for long-lived streaming connections, or firewalls that inspect WebSocket traffic, can throttle or break the connection mid-session, and the recognition request dies silently. Because the proxy intercepts by destination, the chat.openai.com audio route is the one that suffers, while the page's text and images, which schedule retries and tolerate delay, keep working.

Worse, some VPN configurations deliberately filter real-time protocols and media content, either to save bandwidth on the exit node or to avoid interleaving telephony and data traffic. The filtering often targets anything that looks media-shaped, which is precisely the shape of a speech stream. Add the encryption overhead on top and you have a route where the microphone's audio arrives late, fragmented, or never. The logical conclusion is the one that shapes every fix in this article: you cannot repair this by tuning the microphone, only by giving the speech traffic an address path that is not taxed. Keep that sentence in mind while configuring, and you will never again reach for the microphone settings on a VPN day.

The exact menu names differ between VPN clients, but the logic is identical everywhere, and you can adapt any instructions by looking for split tunneling, excluded apps, or routes. The first approach, app-based, is the easiest: find the split-tunneling section of your client and add to the exclusion list the browser you use for ChatGPT, whether that is Chrome, Edge, or Firefox. The whole browser then travels outside the tunnel, which is broader than the ideal scope but is simple, robust, and allows dictation to work while the rest of your system remains encrypted. Some clients offer per-app rules per network, so you can keep the exclusion for guest Wi-Fi but not for the corporate network if you prefer.

The second approach, domain-based, is finer and exists in a subset of clients: instead of excluding the app, you add an exception route for chat.openai.com and its media endpoints. Practical experience shows that speech request servers are not always on the exact same hostname as the page, so a robust rule should cover the root domain, chatgpt.com where it applies, and the WebSocket media endpoints flagged in the network panel if the client lets you specify hosts. If the client supports only one rule, add the entire openai.com root as the exception, which is safe because ChatGPT-dependent Audio domains fall under it anyway. Then reconnect the VPN and test.

Whichever method you use, verify the route rather than assuming it took effect. Check the connection status inside the VPN client for the excluded app or domain, then open a site like a what-is-my-ip service in the excluded browser and confirm it reports the non-VPN address while a second browser still reports the VPN exit. Dictate a test sentence, and if it transcribes, the split is live. One warning: on some clients you must restart the browser or even the VPN app for exclusions to apply, so do the test after a clean restart, and re-check after every VPN update because clients reset their split lists during upgrades.

The numbers from a real trip tell the story better than any theory. On a hotel network, with the VPN fully routed, dictation failed in six out of ten attempts, and when it succeeded the text arrived in bursts with a wait of three to five seconds at the end of each sentence. With the same network and the browser excluded via split tunneling, the same test produced ten out of ten successful transcriptions, with the words appearing as you spoke, effectively in real time. The total change was one configuration switch in the VPN client, and the measured behavior difference was the difference between unusable and excellent.

Latency is the more revealing axis. In the fully tunneled configuration, the time between your last word and the final committed text averaged several seconds, which is long enough to feel like a stall and long enough for you to start wondering whether the session died. With the split in place, final text arrived within the recognition service's normal cadence, indistinguishable from a direct connection. Packet loss played its part as well: the hotel network itself was mediocre, but the tunnel multiplied its effects with a long detour, while the direct path absorbed the same loss without visible degradation, since speech protocols can tolerate a few percent loss when the round trip is short.

The reliability finding generalizes across airports, cafes, and client offices: split tunneling converted voice input from a gamble into a routine. It also introduced one honest tradeoff: the excluded traffic is no longer encrypted by the VPN, which matters if you use a hostile network you do not trust. The resolution that satisfies both concerns is to use HTTPS, which the browser does by default, and to accept that your speech is carried over TLS directly rather than through the VPN. That is exactly the protection level of any normal browser session, and for most travelers it is a fair exchange for a microphone that works.

Turn the fix into a pre-flight check, because problems on the road are best caught before the presentation starts. Ninety seconds before any dictation-dependent session: connect the VPN, apply the browser exclusion, restart the browser, and dictate one test sentence. If the test text arrives, you are set, and you can spend the session thinking rather than debugging. If it does not arrive, check silently: is the exclusion still listed after the client's last auto-update, did the client revert to a strict mode you enabled for another network, and is the connection actually using the split rather than a system-wide proxy? Log the test sentence result, because knowing the difference between works and fails on this network is the most valuable note in your travel log.

Add the network-specific habit for hotels. Hotel Wi-Fi often runs a captive portal that behaves differently for media traffic, and the portal's address exceptions can interact with split rules. After connecting, load a page first, sign into the portal, and only then start the dictation test; some portal sessions expire silently and kill the exclusion along with the session. If speech still fails while browsing works, check whether the hotel filters WebSockets outright; the test then belongs on a mobile hotspot instead, and the routine becomes, any network that breaks speech gets the hotspot treatment. Write the rule on a sticky note in your bag; it has rescued more trips than any other tip in this article.

Finally, keep the configuration documented per environment, since you will not remember three VPN profiles across two laptops. Note the client version, the exclusion type, and the test result for each site you visit, and revisit the note the next time you land there. When the note says split tunneling restored voice on a hotel Wi-Fi and the current session disagrees, you know the client auto-updated, and you fix the list instead of re-diagnosing from zero. The takeaway across every field test is the same: the fix is scoped, repeatable, and boring, and boring is exactly what a traveler wants from a voice workflow.