Could there be design flaws in our request chain causing error rates when using APISIX and iptables as server-level sidecar proxies?

[Jiaoyang-coder]

In a typical physical server deployment environment, we are attempting to use APISIX as a server-level sidecar proxy to proxy cross-server HTTP requests. To maintain unchanged service registration and service discovery in the original project, we use iptables for request interception and NAT to forward outbound requests to the local APISIX. APISIX then obtains the original address information through socketopt, reassembles the original request address, and sends the request using the HTTPS protocol. When the request reaches the target server, iptables intercepts the port and forwards it to the APISIX on the current machine. APISIX again retrieves the original target address from socketopt, reassembles the request, and forwards it to the local service using the HTTP protocol. However, in our actual business pressure tests, we found that even under not very high concurrency, there is still an error rate of about 3%. When we remove iptables and APISIX for pressure testing, the error rate drops to 0. We have tried modifying configurations related to conntrack, somaxconn, port_range, etc., on the Linux server, but none of these have resolved the issue. Could there be any problems with the design of this request chain?