Spring WebClient Proxy Errors: Reactive Handling vs Logging
Distinguish WebClient’s reactive error signal, transport logging, and HTTP status handling during a proxy failure.
A transport can log a failed proxy connection while the application also receives and handles the reactive error. The log entry alone does not establish that the application's handler was skipped.
Follow the error signal in the chain that actually gets subscribed. A try/catch around code merely constructing a Mono is a different scope from handling a later network failure.
| Operator | Effect |
|---|---|
| doOnError | Performs a side effect while the error continues |
| onErrorMap | Transforms an error into another error |
| onErrorResume | Switches to an alternate publisher |
Choose the behavior the application needs. Recording a metric does not require returning fake successful content. An alternate response should be a deliberate application result, not a way to hide a failed route.
Also distinguish transport exceptions from received HTTP error statuses. A proxy connection can fail before an ordinary destination response exists, so an HTTP-status handler may have nothing to inspect. Preserve the cause of a WebClientRequestException when diagnosing the lower-level failure.
Adjust logging only after understanding the outcome. Turning the entire transport logger off can remove evidence needed for a later timeout, TLS problem, or authentication failure without changing the behavior of the reactive pipeline.