Webhook POST requests sent from a mobile device using the TextBee open-source client are successfully received by our EC2 Nginx server. However, instead of being proxied to the backend Spring Boot application via proxy_pass, Nginx immediately responds with a 200 OK status and a 0-byte body, effectively terminating the request. This prevents any webhook data from reaching our application.
In stark contrast, when the exact same webhook endpoint is called using a PowerShell script (Invoke-RestMethod) with a proper JSON body, the request is correctly forwarded to the Spring Boot application. The application then processes it and returns the expected application-level responses (in our tests, 4xx or 5xx errors), which are correctly logged by Nginx.
This indicates that the Nginx proxy configuration itself is functional, but something specific to the axios request from the TextBee client is causing it to be handled improperly by Nginx.
Nginx Access Log
The Nginx access logs show a clear and critical difference between the two types of requests:
# 1\. Request from TextBee (using axios) -\> Fails to reach the Spring server
# Nginx intercepts and returns 200 OK with a 0-byte response body.
75.119.150.119 - - [23/Sep/2025:04:13:09 +0000] "POST /main/api/verification/sms/webhook HTTP/1.1" 200 0 "-" "axios/1.8.2"
# 2\. Request from PowerShell -\> Successfully reaches the Spring server
# The logs record the 410 and 500 error codes returned by the Spring application, along with non-zero response body sizes.
14.50.47.205 - - [23/Sep/2025:04:12:55 +0000] "POST /main/api/verification/sms/webhook HTTP/1.1" 410 85 "-" "Mozilla/5.0 ... WindowsPowerShell..."
14.50.47.205 - - [23/Sep/2025:04:46:58 +0000] "POST /main/api/verification/sms/webhook HTTP/1.1" 500 93 "-" "Mozilla/5.0 (Windows NT 10.0)"
Steps to Reproduce
- Configure Nginx to
proxy_pass requests to a running Spring Boot application with an endpoint expecting a JSON body (e.g., using @RequestBody).
- Send a webhook POST request from the TextBee client app to the configured endpoint (
/main/api/verification/sms/webhook).
- Observe the Nginx access log, which shows a
200 0 response. Note that no logs appear in the Spring Boot application.
- Send a POST request with a valid JSON body to the same endpoint using PowerShell or a similar tool.
- Observe that logs for the request now appear in the Spring Boot application, and Nginx logs the application's response code.
Expected Behavior
POST requests originating from the TextBee client (User-Agent: axios/1.8.2) should be proxied to the backend Spring Boot application, just like any other standard POST request. The final HTTP response, including status code and body, should originate from the Spring application, not be short-circuited by Nginx.
Suspected Cause
Based on the log analysis, the most likely cause is that the webhook POST request from the TextBee client is being sent with an empty or missing request body.
A Spring Boot controller using the @RequestBody annotation requires a non-empty body to function. When Nginx receives a POST request with Content-Length: 0 (or a missing body), its default behavior might be to consider it a malformed/non-proxyable request and simply return 200 OK on its own, rather than forwarding it to an application that would likely return an error.
A missing Content-Type: application/json header could also be a contributing factor.
Environment
- Webhook Source: TextBee (User-Agent:
axios/1.8.2)
- Web Server: Nginx
- Application Server: Spring Boot
- Hosting Environment: AWS EC2
Webhook POST requests sent from a mobile device using the TextBee open-source client are successfully received by our EC2 Nginx server. However, instead of being proxied to the backend Spring Boot application via
proxy_pass, Nginx immediately responds with a 200 OK status and a 0-byte body, effectively terminating the request. This prevents any webhook data from reaching our application.In stark contrast, when the exact same webhook endpoint is called using a PowerShell script (
Invoke-RestMethod) with a proper JSON body, the request is correctly forwarded to the Spring Boot application. The application then processes it and returns the expected application-level responses (in our tests, 4xx or 5xx errors), which are correctly logged by Nginx.This indicates that the Nginx proxy configuration itself is functional, but something specific to the
axiosrequest from the TextBee client is causing it to be handled improperly by Nginx.Nginx Access Log
The Nginx access logs show a clear and critical difference between the two types of requests:
Steps to Reproduce
proxy_passrequests to a running Spring Boot application with an endpoint expecting a JSON body (e.g., using@RequestBody)./main/api/verification/sms/webhook).200 0response. Note that no logs appear in the Spring Boot application.Expected Behavior
POST requests originating from the TextBee client (User-Agent:
axios/1.8.2) should be proxied to the backend Spring Boot application, just like any other standard POST request. The final HTTP response, including status code and body, should originate from the Spring application, not be short-circuited by Nginx.Suspected Cause
Based on the log analysis, the most likely cause is that the webhook POST request from the TextBee client is being sent with an empty or missing request body.
A Spring Boot controller using the
@RequestBodyannotation requires a non-empty body to function. When Nginx receives a POST request withContent-Length: 0(or a missing body), its default behavior might be to consider it a malformed/non-proxyable request and simply return200 OKon its own, rather than forwarding it to an application that would likely return an error.A missing
Content-Type: application/jsonheader could also be a contributing factor.Environment
axios/1.8.2)