**Describe the bug**:
I was faced with a very strange and weird issue. When ELK server fails and responds with 500 error, a current HTTP request fails too and my server responds with 500 status and plain text from ELK response. And this error doesn't pass through any middleware, I have a couple of them, one for sentry integration and another for error message transforming, and none of them was triggered.

This is a full logs from my app:

```python
Failed to submit message: 'HTTP 500: \r\n500 Internal Server Error\r\n\r\n

500 Internal Server Error

\r\n

---

nginx/1.20.1\r\n\r\n\r\n'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/elasticapm/transport/base.py", line 279, in _flush
self.send(data, forced_flush=forced_flush)
File "/usr/local/lib/python3.11/site-packages/elasticapm/transport/http.py", line 114, in send
raise TransportException(message, data, print_trace=print_trace)
elasticapm.transport.exceptions.TransportException: HTTP 500:
500 Internal Server Error

500 Internal Server Error

---

nginx/1.20.1


```

**To Reproduce**

Unfortunately, I can't reproduce it in my dev configuration. It happens only in production environment.
But I guess it happens like that:
1. A python server receives HTTP request from a user for example on root path "/"
2. Around the same time the elk-apm lib tries to send some data to elk server
3. Server responds with 500 error
4. ???
5. Somehow this error passed through to end user, and the user sees 500 error with plain text from the original exception

**Environment (please complete the following information)**
- OS: Debian GNU/Linux 11 (bullseye)
- Python version: 3.11.3
- Framework and version: Fastapi 0.92.0
- APM Server version:
- Agent version: 6.15.1

**Additional context**

- Agent config options

Click to expand

```
APM_ENABLED: 'True'
APM_DEBUG: 'False'
APM_SERVICE_NAME: "project"
APM_ENVIRONMENT: "production"
APM_CLOUD_PROVIDER: "aws"
APM_TRANSACTION_IGNORE_URLS: "[]"
APM_SERVER_URL: "https://some.host"
APM_SERVER_TIMEOUT: "10s"
APM_SAMPLE_RATE: "1.0"
APM_LOG_LEVEL: "info"
APM_TRANSPORT_CLASS: "elasticapm.transport.http.Transport"
```

- `requirements.txt`:

Click to expand

```
alembic==1.9.4
anyio==3.6.2
asyncpg==0.27.0
authlib==1.2.0
certifi==2022.12.7
cffi==1.15.1
click==8.1.3
cryptography==39.0.2
dnspython==2.3.0
elastic-apm==6.15.1
email-validator==1.3.1
fastapi==0.92.0
greenlet==2.0.2
h11==0.14.0
httpcore==0.16.3
httpx==0.23.3
idna==3.4
jinja2==3.1.2
mako==1.2.4
markupsafe==2.1.2
prometheus-client==0.16.0
prometheus-fastapi-instrumentator==5.10.0
psycopg==3.1.8
pycparser==2.21
pydantic[email]==1.10.5
pyjwt==2.6.0
pyotp==2.8.0
python-multipart==0.0.6
rfc3986[idna2008]==1.5.0
sentry-sdk==1.16.0
sniffio==1.3.0
sqlalchemy==2.0.4
starlette==0.25.0
typing-extensions==4.5.0
urllib3==1.26.14
uvicorn==0.20.0
wrapt==1.15.0
```

Commencez par elasticapm/transport/base.py à _flush et elasticapm/transport/http.py à send, puis suivez comment une soumission APM échouée pourrait atteindre une requête FastAPI. Reproduisez le timing de production avec un serveur APM renvoyant HTTP 500 et vérifiez si l’exception contourne le middleware signalé. Le travail est terminé lorsque le chemin d’échec est isolé et couvert par un test de régression.

Rédigé par le modèle d'indexation à partir du texte de l'issue.