Flow processing method and system for reverse proxy series connection
By performing application layer protocol judgment and modular design in the reverse proxy server, the problems of resource waste, poor scalability and high operation and maintenance difficulty in the existing technology are solved, and intelligent traffic processing and standardized verification are realized, improving system performance and observability.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-21
- Publication Date
- 2026-03-13
AI Technical Summary
Existing reverse proxy concatenation solutions are rigid, wasteful of resources, have poor scalability and flexibility, are difficult to maintain, cannot support multiple protocols, and lack observability.
The first reverse proxy server determines the application layer protocol, distinguishes between HTTPS and non-HTTPS traffic, and performs SSL decryption and direct forwarding respectively; the second reverse proxy server performs SSL re-encryption and direct forwarding; the modular design includes traffic classification, SSL decryption, SSL re-encryption, security policy and health management modules to achieve intelligent differentiated processing and standardized verification.
It improves system performance and resource utilization, enables flexible expansion and observability, reduces operational complexity, and ensures the accuracy and stability of processing results.
Smart Images
Figure CN121664476A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer network technology, and more specifically, to a method and system for processing traffic through reverse proxy concatenation. Background Technology
[0002] Reverse proxy servers (such as HAProxy) are widely used to handle traffic between clients and backend servers. A common approach is to use multiple HAProxy instances chained together to distribute traffic and perform SSL encryption / decryption. For example, the first HAProxy instance is responsible for identifying HTTP and HTTPS traffic; HTTP traffic is forwarded directly, while HTTPS traffic is decrypted and forwarded to the second HAProxy instance, which then encrypts and forwards it to the backend server. However, this approach has the following limitations: it can only handle HTTP / HTTPS traffic and cannot support other protocols (such as TCP and UDP); the SSL processing is complex and may introduce performance bottlenecks and single points of failure; and it lacks a flexible traffic classification mechanism, resulting in poor scalability. Therefore, this paper proposes a reverse proxy chaining traffic processing method and system.
[0003] The existing technology has the following shortcomings, specifically:
[0004] 1. Inflexible processing and significant resource waste: Traditional reverse proxy chaining schemes treat all inbound traffic indiscriminately. Whether it's HTTPS traffic requiring complex encryption / decryption operations or simple HTTP plaintext traffic, it must all go through the complete proxy processing chain. This results in unencrypted traffic bearing unnecessary computational overhead, leading to low system resource utilization. Especially during peak traffic periods, encryption / decryption operations can easily become a performance bottleneck.
[0005] 2. Coupling Architecture, Poor Scalability and Flexibility: Existing solutions typically highly couple SSL termination, security filtering, load balancing, and other functions into a single or homogeneous proxy node. This tightly coupled architecture makes it difficult for the system to be independently scaled or upgraded for specific traffic types. For example, when encrypted traffic increases, it is impossible to enhance decryption capabilities without affecting the processing of other traffic.
[0006] 3. Insufficient observability and high maintenance difficulty: Traditional solutions lack standardized verification mechanisms to confirm whether traffic processing (especially the correctness of encryption and decryption) meets expectations. When problems occur, maintenance personnel need to set up temporary packet capture environments and manually correlate data from multiple nodes, which is cumbersome, inefficient, and difficult to reproduce momentary failures. Summary of the Invention
[0007] The purpose of this invention is to provide a traffic processing method for reverse proxy concatenation to solve the problems mentioned in the background art.
[0008] To achieve the above objectives, the present invention aims to provide a traffic processing method for reverse proxy concatenation, comprising: S1: receiving network traffic from a client by a first reverse proxy server, and performing application layer protocol judgment on the network traffic to distinguish between HTTPS traffic and non-HTTPS traffic.
[0009] S2: For the HTTPS traffic identified in S1, the first reverse proxy server performs an SSL decryption operation to generate decrypted plaintext traffic, and sends the decrypted plaintext traffic to the second reverse proxy server.
[0010] S3: For non-HTTPS traffic identified in S1, the first reverse proxy server directly forwards it to the second reverse proxy server.
[0011] S4: The second reverse proxy server receives traffic from the first reverse proxy server. For the received decrypted plaintext traffic, it performs an SSL re-encryption operation and sends it to the backend server. For the received non-HTTPS traffic, it forwards it directly to the backend server.
[0012] As a further improvement to this technical solution, the first reverse proxy server and the second reverse proxy server are software load balancers.
[0013] As a further improvement to this technical solution, the application layer protocol judgment is specifically implemented as follows:
[0014] The first reverse proxy server parses the transport layer port characteristics of traffic, including traffic within the default port range of the corresponding encryption protocol into the HTTPS candidate set, while traffic from other ports is temporarily classified as a non-HTTPS candidate set. For traffic in the candidate set, feature fields of the application layer first packet and subsequent interaction frames are further extracted and verified by matching them against a preset encryption protocol feature library. HTTPS traffic must meet specific frame structure sequences, encryption suite negotiation identifiers, and certificate exchange characteristics during the handshake phase. Non-HTTPS traffic is distinguished by identifying protocol header fields without encryption identifiers and plaintext interaction modes. For abnormal traffic where port characteristics and protocol characteristics do not match, dynamic deep detection technology is used to analyze the encryption identifier bits, data transmission symmetry, and interaction response modes of the traffic, and performs secondary verification in conjunction with a preset protocol behavior model to finally determine the traffic type.
[0015] A second aspect of the present invention provides a system for a reverse proxy concatenated traffic processing method, comprising:
[0016] The traffic classification module, deployed on the first reverse proxy server, is used to determine the application layer protocol of network traffic received from clients and distinguish between HTTPS traffic and non-HTTPS traffic.
[0017] A first processing module, connected to the traffic classification module, is used to process HTTPS traffic, and includes:
[0018] The SSL decryption unit is used to decrypt HTTPS traffic and generate plaintext traffic.
[0019] The first forwarding unit is used to send the plaintext traffic to the second reverse proxy server.
[0020] The second processing module, connected to the traffic classification module, is used to process non-HTTPS traffic and includes:
[0021] The second forwarding unit is used to directly pass non-HTTPS traffic to the second reverse proxy server.
[0022] The third processing module, deployed on the second reverse proxy server, is used to receive traffic from the first reverse proxy server, and includes:
[0023] The SSL re-encryption unit is used to perform SSL re-encryption on received plaintext traffic.
[0024] The backend routing unit is used to forward re-encrypted traffic and received non-HTTPS traffic to the corresponding backend servers.
[0025] As a further improvement to this technical solution, a security policy module is also included, which is connected between the first processing module and the third processing module. This module is used to perform security detection on the plaintext traffic output by the SSL decryption unit and to execute security control policies on the traffic based on the detection results.
[0026] As a further improvement to this technical solution, a health management module is also included, which is used to periodically obtain the health status of the backend servers from the second reverse proxy server, and generate a traffic scheduling policy based on it, and push it to the first reverse proxy server in real time through the control channel, so as to realize intelligent distribution based on the backend status at the traffic entry stage.
[0027] As a further improvement to this technical solution, a verification and analysis module is also included, which is used to simultaneously capture network data packets at the exit of the first reverse proxy server, the entry and exit of the second reverse proxy server, and the entry of the backend server.
[0028] Perform correlation analysis on the captured data packets to verify whether the decryption process of HTTPS traffic on the first reverse proxy server and the re-encryption process on the second reverse proxy server are as expected, and whether the pass-through path of non-HTTPS traffic is correct.
[0029] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0030] 1. Intelligent and differentiated traffic processing is achieved, significantly improving performance. Through precise application layer protocol judgment, HTTPS and non-HTTPS traffic are separated at the entry point, and optimal processing paths are designed for them. HTTPS traffic follows the "decryption -> plaintext processing -> re-encryption" path, while non-HTTPS traffic is directly passed through. This differentiated processing avoids unencrypted traffic bearing unnecessary computational load, concentrating valuable CPU resources on traffic that truly requires encryption and decryption, thereby significantly improving the overall throughput and processing efficiency of the system and reducing request latency.
[0031] 2. A modular architecture with clearly defined responsibilities and flexible scalability was constructed. By decomposing functions into independent modules such as traffic classification, primary processing, secondary processing, security policies, and health management, the architecture was decoupled. This modular design allows each component to be deployed independently and scaled elastically. Closed-loop control and proactive security mechanisms were introduced to enhance system reliability.
[0032] 3. It provides a built-in, standardized quality verification system to ensure operational quality. By synchronously capturing packets and performing correlation analysis at key nodes, it can proactively and continuously verify the correctness of core processing logic (such as encryption and decryption). This provides the system with powerful observability capabilities, enabling operations and maintenance personnel to quickly locate and resolve problems, reducing operational complexity, and ensuring the long-term stability of the system and the accuracy of processing results. Attached Figure Description
[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0034] Figure 1 This is a schematic diagram of the implementation steps of the method of the present invention.
[0035] Figure 2 This is a schematic diagram of the system structure connection of the present invention. Detailed Implementation
[0036] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0037] Example: Please refer to Figure 1 As shown, a traffic processing method for reverse proxy concatenation is provided, including: S1: A first reverse proxy server receives network traffic from a client and performs application layer protocol judgment on the network traffic to distinguish between HTTPS traffic and non-HTTPS traffic.
[0038] In one specific embodiment, the first reverse proxy server and the second reverse proxy server are software load balancers.
[0039] In one specific embodiment, the application layer protocol determination is implemented as follows: The first reverse proxy server parses the transport layer port characteristics of the traffic and includes the traffic within the default port range of the corresponding encryption protocol into the HTTPS candidate set, while traffic from other ports is temporarily classified as a non-HTTPS candidate set. For the traffic in the candidate set, feature fields of the application layer first packet and subsequent interaction frames are further extracted and verified by matching them with a preset encryption protocol feature library. HTTPS traffic must meet the specific frame structure sequence, encryption suite negotiation identifier, and certificate exchange characteristics of the handshake phase. Non-HTTPS traffic is distinguished by identifying protocol header fields without encryption identifiers and plaintext interaction modes. For abnormal traffic where port characteristics and protocol characteristics do not match, dynamic deep detection technology is used to analyze the encryption identifier bits, data transmission symmetry, and interaction response modes of the traffic. Combined with a preset protocol behavior model, a secondary verification is performed to finally determine the traffic type.
[0040] The first reverse proxy server uses multiple virtual network interfaces to receive, classify, and forward traffic. Physical interface Eth1 receives all inbound client traffic. Virtual interface 1 directs HTTPS traffic to the ingress of the first soft load balancer (HAProxy1A). The egress of the first soft load balancer connects to virtual interface 2, sending processed traffic back to the traffic processing framework. Virtual interface 3 directs decrypted traffic from the traffic processing framework to the ingress of the second soft load balancer (HAProxy2A). The egress of the second soft load balancer connects to virtual interface 4, sending processed traffic back to the traffic processing framework. Physical interface Eth3 sends the final traffic to the backend server. Furthermore, the framework internally defines logical interfaces such as Eth2_SSL and Eth2_Forward to distinguish different types of traffic flowing to the next hop.
[0041] The first soft load balancer instance is configured as follows: Its front-end listener is bound to a publicly accessible IP address and port (e.g., 80 and 443) to receive all client requests. In its configuration, ACL rules are set or built-in functions such as `req_ssl_ver` are used to distinguish between HTTPS and non-HTTPS traffic. An SSL certificate and private key are configured for HTTPS traffic to complete decryption. Its back-end configuration points to the listening entry point of the traffic forwarding module.
[0042] The second soft load balancer instance is configured with its front-end listener set to receive incoming traffic. For decrypted HTTPS traffic (now HTTP) from the first soft load balancer, the second soft load balancer establishes a new HTTPS connection with the backend server using the SSL parameters in the server configuration, thus re-encrypting the traffic. For non-HTTPS traffic, it is directly forwarded to the backend server in either TCP or HTTP mode.
[0043] The specific implementation of the dynamic deep detection technology is as follows: For abnormal traffic whose port characteristics and protocol characteristics do not match, the complete protocol stack from the network layer to the application layer is parsed to extract multi-dimensional features, including specific identifier bits (such as Content Type, Version, Length) in the SSL / TLS handshake message, the integrity and timing of the handshake message sequence, the compliance of the certificate chain structure, and the entropy distribution of the application data packets. These features are then matched and similarity calculated in real time with a predefined normal and malicious traffic behavior fingerprint database. At the same time, combined with the historical behavior baseline of the traffic (such as the access frequency of the source IP and the change pattern of the target port), a weighted scoring model is used to perform dynamic risk assessment. Finally, based on whether the comprehensive score exceeds an adaptive threshold, it is determined whether the abnormal traffic should be classified as HTTPS traffic, non-HTTPS traffic, or malicious traffic that should be blocked.
[0044] The specific method for constructing the protocol behavior model is as follows: A training dataset is constructed by collecting and analyzing massive amounts of known network traffic samples (including HTTPS, HTTP, and other TCP / UDP applications); a series of key behavioral features are extracted from each traffic session, including but not limited to the number and direction of packets during the handshake phase, the statistical distribution (mean, variance) of packet size, the regularity of packet arrival time intervals, typical values of connection duration, and the byte frequency distribution of the payload; these features are then supervised or unsupervised learning using machine learning algorithms (such as decision trees, isolated forests, or hidden Markov models) to generate classification or clustering models that can characterize the normal interaction patterns of different protocols; this model is continuously updated in the production environment through an online learning mechanism to adapt to the evolution of network application protocols and the emergence of new traffic patterns.
[0045] The quantification standard for data transmission symmetry is as follows: For a complete network session, the total number of bytes transmitted, the number of data packets, the average data packet size, and the data packet sending frequency are counted from both directions (client to server, server to client). The symmetry is quantified by calculating the ratio of the total number of bytes in uplink and downlink traffic (symmetry ratio), combined with the variance of the data packet number ratio and the response regularity of data packet interactions within a specific time window (such as the pairing ratio of request-response packets). For highly symmetric protocols (such as VPN tunnels), this ratio is close to 1 and has a small variance; for asymmetric protocols (such as traditional HTTP request / response), this ratio deviates significantly from 1. By comparing this comprehensive quantitative indicator with a preset protocol characteristic threshold range, the potential protocol type of the traffic can be determined.
[0046] S2: For the HTTPS traffic identified in S1, the first reverse proxy server performs an SSL decryption operation to generate decrypted plaintext traffic, and sends the decrypted plaintext traffic to the second reverse proxy server.
[0047] The decrypted plaintext traffic is sent to the second reverse proxy server. Specifically, after the first reverse proxy server completes SSL decryption of the HTTPS traffic, it first adds a metadata tag containing the traffic type, original encryption identifier, and processing node information to the decrypted plaintext traffic. Then, through a dedicated encrypted transmission channel established between the first and second reverse proxies, the plaintext traffic with the metadata tag is encapsulated into a data packet conforming to a preset transmission protocol. After the data packet is transmitted to the second reverse proxy server through the channel, the second reverse proxy first verifies the integrity of the metadata tag to confirm the source and legitimacy of the traffic, and then extracts the plaintext content for subsequent processing.
[0048] S3: For non-HTTPS traffic identified in S1, the first reverse proxy server directly forwards it to the second reverse proxy server.
[0049] The specific implementation method of the first reverse proxy server directly forwarding to the second reverse proxy server is as follows: After the first reverse proxy server identifies non-HTTPS traffic, it retains its original protocol format and data structure, and only adds a lightweight forwarding label to identify the traffic type and routing path; through a dedicated transparent transmission channel between the first and second reverse proxy servers, it forwards the traffic without modification according to the original priority order; after receiving the traffic, the second reverse proxy server verifies the forwarding label to confirm the legality of the traffic source, then removes the label and forwards it directly to the backend server according to the original protocol format. The entire process does not involve protocol conversion or data processing, ensuring the transmission efficiency and integrity of non-HTTPS traffic.
[0050] S4: The second reverse proxy server receives traffic from the first reverse proxy server. For the received decrypted plaintext traffic, it performs an SSL re-encryption operation and sends it to the backend server. For the received non-HTTPS traffic, it forwards it directly to the backend server.
[0051] The SSL re-encryption is achieved by enabling the SSL parameter in the backend server configuration of the second reverse proxy server, thereby establishing an HTTPS connection with the backend server as the client.
[0052] Please see Figure 2 As shown, a system for providing a reverse proxy concatenation traffic processing method includes:
[0053] The traffic classification module, deployed on the first reverse proxy server, is used to determine the application layer protocol of network traffic received from clients and distinguish between HTTPS traffic and non-HTTPS traffic.
[0054] A first processing module, connected to the traffic classification module, is used to process HTTPS traffic, and includes:
[0055] The SSL decryption unit is used to decrypt HTTPS traffic and generate plaintext traffic.
[0056] The first forwarding unit is used to send the plaintext traffic to the second reverse proxy server.
[0057] The second processing module, connected to the traffic classification module, is used to process non-HTTPS traffic and includes:
[0058] The second forwarding unit is used to directly pass non-HTTPS traffic to the second reverse proxy server.
[0059] The third processing module, deployed on the second reverse proxy server, is used to receive traffic from the first reverse proxy server, and includes:
[0060] The SSL re-encryption unit is used to perform SSL re-encryption on received plaintext traffic.
[0061] The backend routing unit is used to forward re-encrypted traffic and received non-HTTPS traffic to the corresponding backend servers.
[0062] In one specific embodiment, a security policy module is further included, connected between the first processing module and the third processing module, for performing security detection on the plaintext traffic output by the SSL decryption unit, and executing security control policies on the traffic based on the detection results.
[0063] Security testing specifically refers to multi-level testing of plaintext traffic after SSL decryption, including parsing application layer protocol content to identify malicious request characteristics (such as injected attack code, abnormal parameter formats), analyzing traffic behavior patterns (such as high-frequency repeated requests, atypical data transmission volumes), verifying data integrity (such as comparing preset data fingerprints, detecting unauthorized data tampering), and screening for sensitive information leakage (such as unencrypted account passwords, privacy data fields).
[0064] Implementing security control strategies specifically refers to: taking differentiated processing measures based on security detection results; intercepting traffic confirmed to contain malicious characteristics and recording attack logs; implementing rate limiting or marking and forwarding traffic with abnormal behavior but not clearly malicious; refusing transmission of traffic that fails data integrity verification and reporting verification error information; and triggering desensitization processing before allowing forwarding of compliant traffic containing sensitive information, while simultaneously generating a security audit report and synchronizing it to the management node, thereby achieving full-process security control over decrypted plaintext traffic.
[0065] In one specific embodiment, a health management module is also included, which is used to periodically obtain the health status of the backend servers from the second reverse proxy server, generate a traffic scheduling policy based on the status, and push it to the first reverse proxy server in real time through the control channel, so as to realize intelligent distribution based on the backend status at the traffic entry stage.
[0066] The traffic scheduling strategy generated based on this is as follows: the health management module, based on the acquired health status of the backend servers (including indicators such as response latency, error rate, and resource utilization), first divides the servers into priority queues according to their health levels; then, combining historical traffic processing efficiency with the current load threshold, it assigns dynamic traffic weights to different priority queues; simultaneously, for servers in abnormal states (such as response timeouts or error rate exceeding limits), it automatically generates temporary traffic diversion rules; finally, the traffic scheduling strategy, which includes priority queues, dynamic weights, and traffic diversion rules, is packaged and pushed to the first reverse proxy server through an encrypted control channel to achieve accurate distribution of inbound traffic and automatic avoidance of faulty nodes.
[0067] In one specific embodiment, a verification and analysis module is further included, which is used to simultaneously capture network data packets at the exit of the first reverse proxy server, the entry and exit of the second reverse proxy server, and the entry of the backend server.
[0068] Perform correlation analysis on the captured data packets to verify whether the decryption process of HTTPS traffic on the first reverse proxy server and the re-encryption process on the second reverse proxy server are as expected, and whether the pass-through path of non-HTTPS traffic is correct.
[0069] When performing correlation analysis on the captured data packets, the verification and analysis module first establishes a cross-node association mapping by extracting the source / destination address, session identifier, and timestamp of the data packets. It then performs session-level matching of the plaintext traffic exiting the first reverse proxy server, the plaintext traffic entering the second reverse proxy server, the encrypted traffic exiting the second reverse proxy server, and the encrypted traffic entering the backend server. For HTTPS traffic, it verifies the correctness of the decryption process by comparing the plaintext content of the data packets exiting the first reverse proxy server with the decryption logic of the original encrypted traffic. It verifies the compliance of the re-encryption process by checking the content correspondence between the encrypted traffic exiting the second reverse proxy server and the plaintext traffic entering the second reverse proxy server, the application of encryption algorithms, and the matching degree of certificate information. At the same time, it checks whether the format conversion, metadata carrying, and transmission timing of the traffic at each node meet expectations, based on the preset decryption / encryption process rule base, and finally generates a verification report that includes anomaly location.
[0070] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.
Claims
1. A method for handling traffic in series with a reverse proxy, characterized in that, include: S1: The first reverse proxy server receives network traffic from the client and performs application layer protocol judgment on the network traffic to distinguish between HTTPS traffic and non-HTTPS traffic; S2: For the HTTPS traffic identified in S1, the first reverse proxy server performs an SSL decryption operation to generate decrypted plaintext traffic, and sends the decrypted plaintext traffic to the second reverse proxy server. S3: For non-HTTPS traffic identified in S1, the first reverse proxy server directly forwards it to the second reverse proxy server; S4: The second reverse proxy server receives traffic from the first reverse proxy server. For the received decrypted plaintext traffic, it performs an SSL re-encryption operation and sends it to the backend server. For the received non-HTTPS traffic, it forwards it directly to the backend server.
2. The traffic processing method for a reverse proxy in series according to claim 1, characterized in that, The first reverse proxy server and the second reverse proxy server are software load balancers.
3. The traffic processing method for a reverse proxy in series according to claim 2, characterized in that, The application layer protocol determination is specifically implemented as follows: The first reverse proxy server parses the transport layer port characteristics of traffic, including traffic within the default port range of the corresponding encryption protocol into the HTTPS candidate set, while traffic from other ports is temporarily classified as a non-HTTPS candidate set. For traffic in the candidate set, feature fields of the application layer first packet and subsequent interaction frames are further extracted and verified by matching them against a preset encryption protocol feature library. HTTPS traffic must meet specific frame structure sequences, encryption suite negotiation identifiers, and certificate exchange characteristics during the handshake phase. Non-HTTPS traffic is distinguished by identifying protocol header fields without encryption identifiers and plaintext interaction modes. For abnormal traffic where port characteristics and protocol characteristics do not match, dynamic deep detection technology is used to analyze the encryption identifier bits, data transmission symmetry, and interaction response modes of the traffic, and performs secondary verification in conjunction with a preset protocol behavior model to finally determine the traffic type.
4. A system for performing the reverse proxy concatenation traffic processing method according to any one of claims 1-3, characterized in that, include: The traffic classification module, deployed on the first reverse proxy server, is used to perform application layer protocol judgment on network traffic received from clients and distinguish between HTTPS traffic and non-HTTPS traffic. A first processing module, connected to the traffic classification module, is used to process HTTPS traffic, and includes: The SSL decryption unit is used to decrypt HTTPS traffic and generate plaintext traffic; The first forwarding unit is used to send the plaintext traffic to the second reverse proxy server; The second processing module, connected to the traffic classification module, is used to process non-HTTPS traffic and includes: The second forwarding unit is used to directly forward non-HTTPS traffic to the second reverse proxy server; The third processing module, deployed on the second reverse proxy server, is used to receive traffic from the first reverse proxy server, and includes: The SSL re-encryption unit is used to perform SSL re-encryption on received plaintext traffic; The backend routing unit is used to forward re-encrypted traffic and received non-HTTPS traffic to the corresponding backend servers.
5. The system of the reverse proxy serial traffic processing method according to claim 4, characterized in that, It also includes a security policy module, connected between the first processing module and the third processing module, for performing security detection on the plaintext traffic output by the SSL decryption unit, and executing security control policies on the traffic based on the detection results.
6. The system of the reverse proxy serial traffic processing method according to claim 4, characterized in that, It also includes a health management module, which periodically obtains the health status of the backend servers from the second reverse proxy server and generates a traffic scheduling policy based on it. The policy is then pushed to the first reverse proxy server in real time through the control channel to achieve intelligent distribution based on the backend status at the traffic entry stage.
7. The system of the reverse proxy serial traffic processing method according to claim 4, characterized in that, It also includes a verification and analysis module, which is used to simultaneously capture network packets at the exit of the first reverse proxy server, the entry and exit of the second reverse proxy server, and the entry of the backend server. Perform correlation analysis on the captured data packets to verify whether the decryption process of HTTPS traffic on the first reverse proxy server and the re-encryption process on the second reverse proxy server are as expected, and whether the pass-through path of non-HTTPS traffic is correct.