Gateway method and device for proxy server, equipment and medium
By implementing signature verification and frequency limiting in the proxy server, combined with LRU caching and MD5 signature verification, the security issues of Nginx reverse proxy under replay attacks are solved, achieving efficient request processing and enhanced security, ensuring the stability of the backend server and the security of data transmission.
Patent Information
- Application Number
- CN202511228189.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-29
- Publication Date
- 2026-01-06
AI Technical Summary
When faced with replay attacks, Nginx reverse proxy cannot effectively identify and prevent malicious requests, leading to backend server crashes and affecting normal user services.
By implementing signature verification and frequency limiting in the proxy server, using LRU caching to store request signature information, combining MD5 signature verification to verify request legitimacy, and automatically managing certificates through Let's Encrypt, the system security and performance are improved.
It effectively prevents malicious and frequent duplicate requests, improves system security, reduces latency, enhances data processing efficiency and system performance, simplifies HTTPS configuration, and ensures secure data transmission.
Smart Images

Figure CN121284104A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of communication technology, and in particular to a gateway method, apparatus, device, and medium for a proxy server. Background Technology
[0002] Nginx reverse proxy refers to a service where the IP address of the target server is invisible to the client when the client requests access to it. The proxy server acts as an "intermediary," with the client's request first reaching the proxy server, which then decides which backend server to forward the request to. Reverse proxying can hide backend servers, achieve load balancing, enhance security, and cache static resources.
[0003] Nginx reverse proxy does not effectively identify traffic. When subjected to a replay attack, the forwarded traffic can cause the backend server to crash, resulting in the inability to provide normal services to legitimate users. Summary of the Invention
[0004] The technical problem to be solved by the present invention is to provide a gateway method, apparatus, device and medium for a proxy server, which improves the security of the backend server, can effectively prevent malicious requests and frequent repeated requests, improve system security and ensure uninterrupted normal service.
[0005] In a first aspect, the present invention provides a gateway method for a proxy server, comprising the following steps:
[0006] Step 1: The HTTPS proxy server receives the user's HTTPS request;
[0007] Step 2: Receive the HTTPS request and verify the headers of the HTTPS request, which include a signature; verify whether the signature is correct; if the signature is correct, proceed to Step 3; otherwise, reject the HTTPS request.
[0008] Step 3: Generate a string based on the headers and store it in the LRUMap dictionary. If the string exists, reject the HTTPS request; if the string does not exist, accept the HTTPS request.
[0009] Step 4: Obtain the upstream server address from the headers and forward the traffic to that upstream server address.
[0010] In a second aspect, the present invention provides a gateway device for a proxy server, comprising:
[0011] The request receiving module is used by the HTTPS proxy server to receive HTTPS requests from users.
[0012] The initial judgment module receives an HTTPS request, verifies the headers of the HTTPS request, which include a signature; verifies whether the signature is correct; if the signature is correct, proceed to step 3; otherwise, reject the HTTPS request.
[0013] The next judgment module forms a string based on the headers and stores it in the LRUMap dictionary. If the string exists, the HTTPS request is rejected; if the string does not exist, the HTTPS request is accepted.
[0014] The traffic forwarding module obtains the upstream server address from the headers and forwards the traffic to that upstream server address.
[0015] Thirdly, the present invention provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first aspect.
[0016] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.
[0017] One or more technical solutions provided by this invention have at least the following technical effects or advantages:
[0018] 1. Efficient request processing
[0019] Signature verification and frequency limits can effectively prevent malicious requests and frequent duplicate requests, thus improving system security; using coroutines to achieve bidirectional data transmission improves data processing efficiency and reduces latency.
[0020] 2. Flexible configuration
[0021] The system allows for configuration of log paths, log levels, and listening addresses via command-line parameters, facilitating rapid deployment in different environments. It also supports automatic acquisition and renewal of Let's Encrypt certificates, simplifying HTTPS configuration and improving system security.
[0022] 3. Performance optimization
[0023] Using an LRU cache to store request signature information allows for quick checks to determine if requests are too frequent, thus improving performance.
[0024] 4. Safety
[0025] Verify the legitimacy of requests using MD5 signatures to prevent forged requests; ensure the security of data transmission by automatically managing certificates through Let's Encrypt.
[0026] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description
[0027] The present invention will be further described below with reference to the accompanying drawings and embodiments.
[0028] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention;
[0029] Figure 2 This is a schematic diagram of the device in Embodiment 2 of the present invention. Detailed Implementation
[0030] The overall concept of the technical solution in this application is as follows:
[0031]
[0032]
[0033]
[0034]
[0035]
[0036]
[0037]
[0038]
[0039]
[0040]
[0041]
[0042]
[0043]
[0044]
[0045]
[0046]
[0047] The above code is explained as follows:
[0048] I. Program startup initialization (executed only once)
[0049] 1. Parse command-line arguments: Use flag.Parse() to read configurations such as -version (version check), -log-path (log path), and -listen (listen address). If -version is triggered, print the version and exit.
[0050] 2. Initialize the logging system: Call log.Reset() to set the log level (default info) and output path according to the parameters, and complete the logging module configuration;
[0051] 3. Record version information: Execute constant.LogVersion() to write the gateway version to the log for problem tracing;
[0052] 4. Configure Let's Encrypt certificate manager: Create autocert.Manager, set the terms of service, domain whitelist (AUTOCERT_DOMAIN), and certificate cache directory (AUTOCERT_CACHE) to enable automatic application and management of TLS certificates;
[0053] 5. Create a global context: A global context is generated using context.WithCancel(context.Background()) for gracefully exiting the application;
[0054] 6. Initialize core components:
[0055] Call app.New() to create an application processor and initialize an LRU cache with a capacity of 8192 (for request frequency control);
[0056] Call connector.NewDefaultConnector(nil) to create a connector that supports TCP and H2 protocol connections;
[0057] Call route.New() to create a route handler, and associate it with the global context, application handler, and connector;
[0058] 7. Start the HTTP verification service: Start the service on port 80 by using `go http.ListenAndServe(":http",certManager.HTTPHandler(nil))` to respond to Let's Encrypt's HTTP-01 certificate verification requests;
[0059] 8. Start the HTTPS proxy service: Create http.Server, configure the listening address (default: 443), set the route handler as the request processing entry point, configure TLS (only supports HTTP / 2, dynamically obtained certificates), and finally call server.ListenAndServeTLS("","") to start the service;
[0060] II. Request Reception and Context Preparation (Executed once for each received request)
[0061] 1. Listen for and receive requests: The HTTPS service listens on a specified port and triggers the Route.ServeHTTP() method upon receiving a client request;
[0062] 2. Check system status: Monitor the global context using select. If the program is exiting (triggered by r.ctx.Done()), directly reject the request and return.
[0063] 3. Create a request context:
[0064] Call context.WithCancel(req.Context()) to generate a request-specific cancelable context;
[0065] Call adapter.NewDownstreamContext() to encapsulate the request (req) and response writer (rw) into DownstreamContext for unified management of request-related data;
[0066] 4. Enter the main request processing logic: Call r.handle(ctx) to process the request; if an error is returned, execute r.renderError() to generate an error response.
[0067] III. Request Validation (RequestFilter)
[0068] 1. Extract request header parameters: Retrieve the three key request headers from ctx.Request(): ts (timestamp), nonce (random string), and sign (signature);
[0069] 2. Verify request signature:
[0070] Initialize the MD5 hash object, concatenate md5Salt (fixed salt value S1ngJump; B0sk3tb@ll), ts, and nonce as the signature source string and write them into the hash object;
[0071] Convert the hash result to a hexadecimal string and compare it with the request header sign. If they do not match, return the ErrorTypeRequestFilterValidateFailed error.
[0072] 3. Control request frequency:
[0073] Generate cache key: concatenate client IP (ctx.RemoteAddr()), ts, and nonce;
[0074] Check the LRU cache. If the key exists in the cache, return an ErrorTypeRequestFilterTooFrequent error; otherwise, add the key to the cache.
[0075] 4. Inject Log ID: Call ctx.AppendContext(log.ContextWithID(ctx.LastContext(),nonce)) to use nonce as a unique log ID and associate it with the entire request log.
[0076] IV. Upstream Service Configuration Analysis (UpstreamPeer)
[0077] 1. Extract upstream configuration: Retrieve the peer field (Base64 encoded upstream configuration) from the request header. If it is empty, return the ErrorTypeRequestHeaderMissingPeer error.
[0078] 2. Base64 decoding: Use base64.RawURLEncoding.DecodeString(peerStr) to decode the peer value. If decoding fails, return an ErrorTypeRequestHeaderInvalidPeer error.
[0079] 3. Parse the configuration structure: Parse the decoded byte stream into an option.PeerOptions structure using json.Unmarshal(). If parsing fails or the configuration fails peer.Validate() validation, return an ErrorTypeRequestHeaderInvalidPeer error.
[0080] 4. Store upstream configuration: Call ctx.SetPeer(peer) to store the valid upstream configuration in the request context for use in subsequent connections;
[0081] V. Upstream Connection Establishment and Filtering (ConnectFilter)
[0082] 1. Establish upstream connection: Call connector.DialContext(), select the corresponding connector (TcpConnector / H2Connector) based on peer.Type (tcp / h2) to establish a connection with the upstream service, and return the corresponding error if the connection fails;
[0083] 2. Connection filtering: Call r.inner.ConnectFilter(ctx, upstream) to filter established upstream connections (the current code directly returns the original connection, reserving for future expansion capabilities). If filtering fails, the connection is closed and an error is returned.
[0084] 3. Record connection logs: Call log.Trace() to write the upstream service connection information (peer.Summarize()) to the log;
[0085] VI. Response Configuration (ResponseFilter)
[0086] 1. Set response headers: Call rw.Header().Set("Cache-Control","no-store") to disable client caching of proxy responses;
[0087] 2. Get the response status code: Call r.inner.ResponseFilter(ctx) to get the response status code (currently it always returns http.StatusOK), or return an error if an error occurs;
[0088] 3. Write status code: Call rw.WriteHeader(statusCode) to send the HTTP response status code to the client;
[0089] VII. Bidirectional Data Forwarding (Core Proxy Logic)
[0090] 1. Start dual-coroutine data stream processing:
[0091] Downstream→Upstream forwarding coroutine: Reads the client request body (ctx.Request().Body), writes the data to the upstream connection using r.copy(), and records the number of bytes forwarded (down2UpN); after forwarding is complete, if it is normal, it closes the upstream writing end; if there is an error, it closes the entire upstream connection.
[0092] Upstream→Downstream forwarding coroutine: Creates flushResponseWriter (automatically flushes the buffer), reads upstream connection data and writes it to the client response using r.copy(), and records the number of bytes forwarded (up2DownN); closes the client response writing end after forwarding is complete;
[0093] 2. Merge forwarding results: Receive the execution results of the two coroutines through the channel, call errors.Join() to merge possible errors, and obtain the final number of bytes forwarded in both directions and error information;
[0094] 8. Request Logs and Error Responses
[0095] 1. Record request information: Trigger r.inner.Record() in defer to write the client IP, upstream configuration summary, number of bytes forwarded in both directions, and error code to the log, completing the full-link recording of the request;
[0096] 2. Error response handling (executed only when request processing encounters an error):
[0097] If the error includes an HTTP status code (err.HttpStatus()>0), return that status code and its corresponding description directly.
[0098] If it is a request class error (err.IsRequest()), it returns 400 Bad Request;
[0099] If a connection error (err.IsConnect()) occurs, a 502 Bad Gateway error is returned.
[0100] Example 1
[0101] like Figure 1 As shown, this embodiment provides a gateway method for a proxy server, including the following steps:
[0102] Step 1: The HTTPS proxy server receives the user's HTTPS request;
[0103] Step 2: Receive the HTTPS request and verify the headers of the HTTPS request, which include a signature; verify whether the signature is correct; if the signature is correct, proceed to Step 3; otherwise, reject the HTTPS request.
[0104] Step 3: Generate a string based on the headers and store it in the LRUMap dictionary. If the string exists, reject the HTTPS request; if the string does not exist, accept the HTTPS request.
[0105] Step 4: Obtain the upstream server address from the headers and forward the traffic to that upstream server address.
[0106] In this embodiment, preferably, step 1 specifically involves: creating an ACME certificate manager for automatically obtaining Let's Encrypt certificates; starting an HTTP server for ACME challenge verification; starting an HTTPS proxy server; and the HTTPS proxy server receiving HTTPS requests from users.
[0107] In this embodiment, preferably, step 2 specifically involves: receiving an HTTPS request and verifying the headers of the HTTPS request; the headers include: a timestamp, a random number, a signature, and the address of the upstream server; verifying whether the signature is correct; calculating an MD5 hash of the timestamp and the random number according to a set method to obtain a hash value; comparing the hash value with the signature; if the signature is correct, proceeding to step 3; otherwise, rejecting the HTTPS request.
[0108] In this embodiment, preferably, step 3 specifically involves: obtaining the user's IP address, obtaining the timestamp and random number based on the headers, concatenating the user's IP address, timestamp, and random number to form a string, and storing it in the LRUMap dictionary. If the string exists, the HTTPS request is rejected; if the string does not exist, the HTTPS request is accepted.
[0109] Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2.
[0110] Example 2
[0111] like Figure 2 As shown, this embodiment provides a gateway device for a proxy server, including:
[0112] The request receiving module is used by the HTTPS proxy server to receive HTTPS requests from users.
[0113] The initial judgment module receives an HTTPS request, verifies the headers of the HTTPS request, which include a signature; verifies whether the signature is correct; if the signature is correct, proceed to step 3; otherwise, reject the HTTPS request.
[0114] The next judgment module forms a string based on the headers and stores it in the LRUMap dictionary. If the string exists, the HTTPS request is rejected; if the string does not exist, the HTTPS request is accepted.
[0115] The traffic forwarding module obtains the upstream server address from the headers and forwards the traffic to that upstream server address.
[0116] In this embodiment, preferably, the request receiving module specifically comprises: creating an ACME certificate manager for automatically obtaining Let's Encrypt certificates; starting an HTTP server for ACME challenge verification; starting an HTTPS proxy server; and the HTTPS proxy server receiving HTTPS requests from users.
[0117] In this embodiment, preferably, the initial judgment module specifically performs the following steps: receiving an HTTPS request and verifying the headers of the HTTPS request; the headers include: timestamp, random number, signature, and upstream server address; verifying whether the signature is correct; calculating the MD5 hash of the timestamp and random number according to a set method to obtain the hash value; comparing the hash value with the signature; if the signature is correct, proceeding to step 3; otherwise, rejecting the HTTPS request.
[0118] In this embodiment, preferably, the re-judgment module specifically performs the following steps: obtain the user's IP address, obtain the timestamp and random number based on the headers, concatenate the user's IP address, timestamp, and random number to form a string, and store it in the LRUMap dictionary. If the string exists, the HTTPS request is rejected; if the string does not exist, the HTTPS request is accepted.
[0119] Since the apparatus described in Embodiment 2 of the present invention is an apparatus used to implement the method of Embodiment 1 of the present invention, those skilled in the art can understand the specific structure and variations of the apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be described again here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of the present invention.
[0120] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to Embodiment 1, as detailed in Embodiment 3.
[0121] Example 3
[0122] This embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement any of the implementation methods in Embodiment 1.
[0123] Since the electronic device described in this embodiment is the device used to implement the method in Embodiment 1 of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in Embodiment 1 of this application. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiment of this application falls within the scope of protection of this application.
[0124] Based on the same inventive concept, this application provides a storage medium corresponding to Embodiment 1, as detailed in Embodiment 4.
[0125] Example 4
[0126] This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it can implement any of the implementation methods in Embodiment 1.
[0127] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0128] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0129] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0130] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0131] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the invention should be covered within the scope of protection of the claims of the present invention.
Claims
1. A gateway method for a proxy server, characterized by: The method comprises the following steps: Step 1, the HTTPS proxy server receives the HTTPS request of the user; Step 2, receiving the HTTPS request, checking the headers of the HTTPS request, the headers comprising a signature; checking whether the signature is correct; if the signature is correct, entering step 3, otherwise, rejecting the HTTPS request; Step 3, forming a string according to the headers, saving in the LRUMap dictionary, if the string exists, rejecting the HTTPS request; if the string does not exist, receiving the HTTPS request; Step 4, obtaining the upstream server address from the headers, forwarding the traffic to the upstream server address.
2. The gateway method for a proxy server according to claim 1, wherein: The step 1 is specifically: creating an ACME certificate manager for automatically obtaining Let's Encrypt certificate; starting an HTTP server for ACME challenge verification; starting an HTTPS proxy server; the HTTPS proxy server receives the HTTPS request of the user.
3. The gateway method for a proxy server according to claim 1, wherein: The step 2 is specifically: receiving the HTTPS request, checking the headers of the HTTPS request; the headers comprising: timestamp, random number, signature and upstream server address; checking whether the signature is correct; calculating MD5 hash according to the set mode of the timestamp and the random number, obtaining a hash value, comparing the hash value with the signature, if the signature is correct, entering step 3, otherwise, rejecting the HTTPS request.
4. The gateway method for a proxy server according to claim 1, wherein: The step 3 is specifically: obtaining the user IP, obtaining the timestamp and the random number according to the headers, connecting the user IP, the timestamp and the random number to form a string, saving in the LRUMap dictionary, if the string exists, rejecting the HTTPS request; if the string does not exist, receiving the HTTPS request.
5. A gateway device for a proxy server, characterized by: The method comprises: a request receiving module, the HTTPS proxy server receives the HTTPS request of the user; a first judgment module, receiving the HTTPS request, checking the headers of the HTTPS request, the headers comprising a signature; checking whether the signature is correct; if the signature is correct, entering step 3, otherwise, rejecting the HTTPS request; a second judgment module, forming a string according to the headers, saving in the LRUMap dictionary, if the string exists, rejecting the HTTPS request; if the string does not exist, receiving the HTTPS request; a traffic forwarding module, obtaining the upstream server address from the headers, forwarding the traffic to the upstream server address.
6. The gateway device for a proxy server according to claim 5, wherein: The request receiving module is specifically: creating an ACME certificate manager for automatically obtaining Let's Encrypt certificate; starting an HTTP server for ACME challenge verification; starting an HTTPS proxy server; the HTTPS proxy server receives the HTTPS request of the user.
7. The gateway device for a proxy server according to claim 5, wherein: The first judgment module is specifically: receiving the HTTPS request, checking the headers of the HTTPS request; the headers comprising: timestamp, random number, signature and upstream server address; Check if the signature is correct; calculate MD5 hash according to the set mode with the timestamp and random number, get the hash value, compare the hash value with the signature, if the signature is correct, go to step 3, otherwise, reject the HTTPS request.
8. The gateway device for a proxy server according to claim 5, wherein: The re-judging module is specifically: obtaining the user IP, obtaining the timestamp and random number according to the headers, connecting the user IP, the timestamp and the random number to form a string, saving the string in the LRUMap dictionary, if the string exists, rejecting the HTTPS request; If the string does not exist, receiving the HTTPS request.
9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to realize the method of any one of claims 1 to 4.
10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to realize the method of any one of claims 1 to 4.