You're probably making an “international transfer” here, but that doesn't mean it is illegal.
The GDPR has a very broad concept of “personal data” and of “processing”. Per Art 4(2),
‘processing’ means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction
Which I would summarize as: pretty much anything you do with the personal data counts as “processing”.
So yes, your non-EU servers would be processing the personal data in HTTP requests, even when those servers aren't directly storing the personal data.
Chapter V of the GDPR applies to
Any transfer of personal data which are undergoing processing or are intended for processing after transfer to a third country […]
Per this definition, the question whether an international transfer occurred is inextricably linked with the question whether the data is being processed in the destination country. The generally accepted interpretation here is that mere transfer through a country does not constitute processing. For example, if your requests happen to take a network route through other countries, that wasn't an international transfer.
But your HTTP server is definitely doing processing, even if it doesn't store the data persistently.
If the HTTP server is in a non-EU country, then you have to consider how this transfer of data is protected. You're supposed to uphold the high GDPR data protection standards regardless of where the processing occurs.
Some countries have been granted an EU adequacy decision, meaning that their data protection laws are sufficiently similar to EU laws and no extra bureaucracy is needed for that transfer. The transfer still needs to be noted in your privacy notice (compare Art 13(1)(f)).
In other cases, you may be able to rely on “standard contractual clauses” (SCCs), which are pre-formulated contracts provided by the EU that translate relevant GDPR aspects into a private contract between the data exporter and data importer. However, you as a data controller must make sure that the data importer is legally able to enter into that contract. For example, the terms of these SCCs are incompatible with US national security laws, meaning that US companies might not be able to enter into the SCCs.
There are a couple of other ways to authorize international transfers, but they are mostly relevant for multinational groups of companies, or in exceptional situations.
In any case, other GPDR requirements like the need to have a suitable contract with your data processors remain unaffected.
Also unaffected is the obligation to implement appropriate technical and organizational measures to ensure the compliance and security of your processing activities (e.g. see Art 24 and Art 32 of the GDPR). For example, this may imply the need to implement suitable encryption.
In the wake of the Schrems II ruling that struck down the EU–US “Privacy Shield” adequacy decision, the EDPB published recommendations on extra compliance measures that could allow SCCs to remain valid for EU–US data transfers. But it's not easy to defend data processing activities when potential adversaries include literally the NSA, and measures such as end-to-end encryption (E2EE) are incompatible with cloud services that are more interesting than backup storage.
Practically speaking, I would reconsider an architecture that would allow failover of EU data processing operations to non-EU locations, unless those target countries are covered by an adequacy decision. If you need a high availability setup for EU activities, it may be more appropriate to maintain multiple deployments within the EU.