Capacitor Web View Networking vs Native HTTP Client: DNS & TLS Interoperability

Answer

Capacitor’s default HTTP plugin uses the embedded Web View (WKWebView on iOS, Chromium‑based System WebView on Android) for all fetch/XMLHttpRequest traffic. Consequently DNS look‑ups and TLS validation follow the Web View’s networking stack, which caches DNS results and relies on the web engine’s trust store. A native HTTP client (OkHttp on Android, URLSession on iOS) bypasses the Web View and talks directly to the platform’s HTTP stack, allowing explicit DNS overrides, custom trust stores, certificate pinning and TLS version selection.

Confirmed facts

• Capacitor apps run UI in the platform Web View; network requests made via fetch/XHR travel through that Web View’s networking stack.
• The Web View uses the system DNS resolver but maintains its own DNS cache that is not flushed when the system DNS changes unless the Web View process is restarted.
• TLS verification in the Web View depends on the web engine’s built‑in trust store (Chromium root set on Android, Apple root set on iOS) and does not expose an API for custom pinning or adding user‑installed CAs.
• A native HTTP client (Capacitor HTTP plugin, OkHttp, URLSession) uses the platform’s native HTTP stack, honors system DNS settings immediately, and allows developers to configure custom trust anchors, certificate pinning and TLS options.

Likely explanation

• When the device switches VPNs, joins a private DNS, or updates /etc/hosts, the Web View may continue to return stale IP addresses until its internal DNS cache expires (typically a few minutes to several hours, depending on the web engine’s TTL handling) or until the Web View is recreated.
• Because the Web View trusts only its bundled root set, newly installed user CAs (e.g., enterprise certificates) are not trusted unless the Web View is rebuilt with those roots added, which is not possible at runtime.
• These differences can cause a request to succeed when made through a native client but fail (or resolve to the wrong host) when made through the Web View, affecting reliability when network configuration changes.

Steps to evaluate DNS/TLS behavior

1. Run the app on a device and issue a request to a hostname that has a custom DNS entry (e.g., via /etc/hosts on Android or a DNS override profile on iOS).
2. Compare the IP address resolved by a fetch/XHR call with the address resolved by a native HTTP call (using the Capacitor HTTP plugin or platform‑specific code).
3. Toggle the system DNS (switch VPN, change private DNS) and repeat the request after a short interval; observe whether the Web View call still returns the old address while the native call reflects the new one.
4. For TLS, serve a self‑signed certificate signed by a user‑installed CA and verify whether the Web View request fails with a certificate error while the native request succeeds after adding the CA to the app’s trust store.
5. On Android, enable Chrome netlog (adb shell setprop log.tag.WebView DEBUG) or capture a bugreport to see DNS queries and TLS handshakes for both stacks. On iOS, use the Network Link Conditioner or console logs from WKWebView delegates and URLSession, or capture packets with rvictl and Wireshark.

Recommendation

Given the deterministic DNS resolution and flexible TLS handling offered by a native HTTP client, exposing a separate native networking module in Capacitor improves reliability for apps that must react to system DNS or certificate store changes. The Web View stack should remain the default for UI‑compatible fetch/XHR calls to preserve API compatibility, but developers should be able to opt‑in to the native client when precise network control is required.