Network fault diagnosis method, device, equipment, medium and program product

Abstract

The invention relates to the technical field of computers, and provides a network fault diagnosis method, device and equipment, a medium and a program product.The network fault diagnosis method comprises the steps that firstly, current network state data are obtained; then, performing feature matching analysis on the acquired network state data according to a corresponding detection logic by means of a pre-constructed fault feature library so as to obtain a corresponding feature matching analysis result; and finally, based on the feature matching analysis result, determining a specific network fault type. According to the invention, the specific type of the network fault can be automatically and standardly identified, and the network fault diagnosis efficiency is improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to a method, apparatus, device, medium, and program product for diagnosing network faults. Background Technology

[0002] In related technologies, when terminal devices encounter network connectivity problems, troubleshooting typically relies on manual methods or single-function tools. For example, users might need to check bandwidth using speed test tools and network configuration through system settings, with the entire process depending on human experience for comprehensive judgment. This decentralized and non-automated troubleshooting approach is not only slow but also leads to unnecessary consumption of computing resources and network signaling overhead as terminal devices perform multiple independent and potentially redundant network probes and status checks. Furthermore, inefficient fault location prolongs the duration of abnormal network conditions, increases the undue pressure on associated server resources, and ultimately reduces the automation level and resource utilization efficiency of network operations and maintenance.

[0003] Therefore, designing a technical solution that can effectively integrate multi-dimensional network status information and achieve automated and precise fault location has become the key to improving the efficiency and accuracy of terminal network problem diagnosis. Summary of the Invention

[0004] This disclosure provides a network fault diagnosis method, apparatus, device, medium, and program product to solve the problems of low efficiency and inaccuracy in network fault diagnosis in related technologies.

[0005] In a first aspect, embodiments of this disclosure provide a network fault diagnosis method, the method comprising: Obtain network status data; Based on the fault feature library, feature matching analysis is performed on the network status data according to the detection logic to obtain the feature matching analysis results; Based on the feature matching analysis results, the network fault type is determined.

[0006] The network fault diagnosis method provided in this disclosure provides an objective data foundation for subsequent fault analysis by acquiring network status data. Based on a fault feature library, feature matching analysis is performed on the network status data according to detection logic, which can systematically compare discrete network data with known fault modes to obtain accurate feature matching analysis results. Furthermore, the network fault type is determined based on the feature matching analysis results, realizing the effect of automated processing of network data and accurate location of fault types, thereby helping to diagnose network faults quickly and accurately, and improving the efficiency and accuracy of network fault handling.

[0007] In one optional implementation, the network fault type includes at least one of device configuration faults and network performance faults; the detection logic includes: First, perform feature matching analysis on the device configuration parameters related to device configuration in the network status data to identify whether there are device configuration-related faults. If no device configuration-related faults are identified, feature matching analysis is performed on network performance indicators related to network performance in the network status data to identify whether network performance-related faults exist.

[0008] The embodiments disclosed herein can also prioritize the identification and elimination of blocking faults caused by user configuration errors, avoid performing meaningless performance tests under configuration errors, thereby effectively preventing misjudgments caused by configuration masking performance problems and improving the execution efficiency of the diagnostic process.

[0009] In one alternative implementation, the device configuration parameters include network proxy and routing configuration parameters.

[0010] In one optional implementation, the network proxy and routing configuration parameters include the virtual private network status; identifying whether there are device configuration-related faults includes: When a virtual private network is detected to be enabled, a device configuration fault is identified.

[0011] In one optional implementation, the network proxy and routing configuration parameters include the network proxy status; identifying whether there are device configuration-related faults includes: When a network proxy is detected to be enabled, a device configuration fault is identified.

[0012] In one optional implementation, the network proxy and routing configuration parameters include the Domain Name System (DNS) server address; identifying whether there are device configuration-related faults includes: When the address of the currently used Domain Name System (DNS) server is detected to exist in the preset list of abnormal DNS systems, a device configuration fault is determined to exist.

[0013] In one optional implementation, the network proxy and routing configuration parameters include gateway address acquisition status; identifying whether there are device configuration-related faults, including: When a valid gateway address cannot be obtained, a device configuration fault is identified.

[0014] This disclosure also utilizes the coordinated detection of multiple key device configuration parameters to accurately identify and differentiate configuration-related faults from different root causes. Specifically, detecting the VPN status can identify network channel detours or interruptions caused by VPN software anomalies or routing policy conflicts; detecting the network proxy status helps identify network access failures caused by manually or maliciously configured incorrect proxy servers; detecting the currently used Domain Name System (DNS) server address and comparing it with a preset malicious DNS list can effectively identify DNS hijacking, poisoning, or slow or incorrect domain name resolution caused by configuring high-latency overseas DNS servers; detecting the gateway address acquisition status can determine whether the device has successfully obtained a valid network configuration from the LAN DHCP service, thereby locating LAN connection failures caused by IP address conflicts or abnormal router DHCP service. Through the above multi-parameter detection, a refined delineation of network configuration problems on the device side is achieved.

[0015] In one alternative implementation, identifying the presence of network performance-related faults includes: The first analysis result is generated based on network performance metrics; Based on the initial analysis results, the specific types of network performance failures were determined.

[0016] In one optional implementation, network performance metrics include target application traffic rate and global traffic rate; a first analysis result is generated based on the network performance metrics, including: The relationship between the target application traffic rate and a first preset threshold, and the relationship between the global traffic rate and a second preset threshold are determined to generate traffic analysis results. The first analysis result includes the traffic analysis results; wherein the first preset threshold is less than the second preset threshold.

[0017] In one alternative implementation, the global traffic rate is obtained in the following way: Within a preset time interval, obtain the difference between the total traffic statistics of the operating system; The global flow rate is calculated based on the difference and the preset time interval.

[0018] In one optional implementation, based on the first analysis results, the specific type of network performance-related fault is determined, including: When the traffic analysis results indicate that the target application's traffic rate is less than or equal to the first preset threshold, and the global traffic rate is greater than the second preset threshold, the specific type is determined to include bandwidth occupancy fault. When the traffic analysis results indicate that the target application traffic rate is less than or equal to a first preset threshold, and the global traffic rate is less than or equal to a second preset threshold, the specific type is determined to include network link quality failure.

[0019] This embodiment of the disclosure, when troubleshooting network performance faults, is no longer limited to a single network speed indicator, but simultaneously considers the target application's own traffic rate and the overall global traffic rate. It comprehensively diagnoses the network condition by determining whether both have reached their respective set baselines (i.e., preset thresholds). To smoothly implement this comparison without obtaining extremely high system privileges (such as non-root privileges), this embodiment of the disclosure uses the difference in the total operating system traffic statistics within a preset time interval to approximate the current global traffic rate, significantly improving the efficiency and accuracy of fault handling.

[0020] In one alternative implementation, generating a first analysis result based on network performance metrics includes: Probe data packets are sent to multiple network nodes to obtain node connectivity analysis results. The first analysis result includes the node connectivity analysis results.

[0021] In one optional implementation, the multiple network nodes include content delivery network nodes and public network reference nodes; the node connectivity analysis results include the connectivity status of the content delivery network nodes and the connectivity status of the public network reference nodes.

[0022] In one optional implementation, based on the first analysis results, the specific type of network performance-related fault is determined, including: When the connectivity status of a content delivery network node is abnormal, while the connectivity status of a public network reference node is normal, the specific type is determined to include node access quality failure. When the connectivity status of the public network reference node is abnormal, the specific type is determined, including network link connectivity failure.

[0023] This disclosure also proactively sends probe data packets to multiple network nodes, including content delivery network nodes and public network reference nodes, to obtain node connectivity analysis results. Then, based on different combinations of these two types of node connectivity states, it accurately determines the specific type of network performance-related faults. This effectively separates "specific service link or local routing failures" (i.e., CDN node abnormalities while public network nodes are normal) from "overall paralysis of the user's external network" (i.e., public network node abnormalities), avoiding blind spots and misjudgments caused by single-node probes and significantly improving the accuracy of fault diagnosis.

[0024] In one optional implementation, the detection logic includes, in descending order of diagnostic level: Physical network connectivity and application permission check hierarchy; Device network configuration parameter check level; Local area network gateway connectivity check level; Network traffic congestion analysis hierarchy; And the remote node connectivity check hierarchy; If a fault is identified at a higher priority level, the feature matching analysis at a lower priority level will be stopped.

[0025] This disclosure also establishes a diagnostic hierarchy from high to low (physical and permissions, configuration, gateway, traffic, node connectivity), and stops subsequent detection when a high-priority level is hit. This mechanism significantly improves execution efficiency and reduces the time spent on redundant detection.

[0026] In one optional implementation, the network status data further includes application network request logs; determining the type of network failure also includes: Extract the status codes returned by network requests from the application's network request logs; Count the number of consecutive occurrences of a specific pre-defined error code in the status codes; When the number of consecutive occurrences exceeds the preset safety threshold, the network fault type is determined to include wireless LAN access restriction fault.

[0027] In one optional implementation, the preset specific error code includes the 403 Forbidden code in the HTTP protocol; Count the number of consecutive occurrences, including: counting the number of times a specific preset error code appears continuously in the application's network request log.

[0028] This disclosure also identifies wireless LAN access restriction faults by analyzing the consecutive occurrences of specific error codes (such as HTTP 403 Forbidden) in application network request logs. This type of fault manifests as a normal physical network connection, but a network layer policy that restricts logical access prohibits access to specific services or domains. Identifying such faults has clear technical significance: it can distinguish between superficial "network unusable" or "application unable to connect" problems and genuine network link quality faults (such as weak signal or high latency). Based on this delineation, precise troubleshooting guidance can be provided to users, such as prompting them that "the current network may have access restrictions; it is recommended to try switching to mobile data network" or "this problem may be caused by network administrator policies," thereby avoiding ineffective troubleshooting by users misjudging it as a network signal problem (such as restarting the router or moving location), significantly improving the efficiency and accuracy of fault handling.

[0029] In one alternative implementation, prior to the step of performing feature matching analysis on the network state data, the method further includes: Detect the physical network connection status of the terminal device and the network permission status of the target application; If the physical network connection status is disconnected, it is determined that there is a physical connection failure; If the physical network connection status is connected and the network access permission status is prohibited, then an application permission failure is determined.

[0030] This disclosure also allows for the early detection of basic errors by prioritizing the investigation of fundamental physical switches or permission settings, thus preventing the execution of complex feature matching algorithms when the network is down or permissions are not available.

[0031] In one alternative implementation, after determining the network fault type of the terminal device, the method further includes: Based on the identified network fault type, the corresponding repair strategy is matched from the preset solution knowledge base, and repair guidance instructions are generated based on the repair strategy.

[0032] This disclosure also enables the transformation of professional technical diagnostic results into user-executable operational guidelines, allowing users to independently repair network problems without requiring professional network knowledge, thereby effectively reducing the operational threshold for users.

[0033] Secondly, embodiments of this disclosure provide a network fault diagnosis device, the device comprising: The acquisition module is used to acquire network status data; The analysis module is used to perform feature matching analysis on network status data based on the fault feature library and according to the detection logic to obtain the feature matching analysis results. The determination module is used to determine the type of network fault based on the results of feature matching analysis.

[0034] Thirdly, this disclosure provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the network fault diagnosis method described in the first aspect or any corresponding embodiment.

[0035] Fourthly, embodiments of this disclosure provide a computer-readable storage medium storing computer instructions for causing a computer to perform the network fault diagnosis method described in the first aspect or any corresponding embodiment.

[0036] Fifthly, embodiments of this disclosure provide a computer program product, including computer instructions, which are used to cause a computer to execute the network fault diagnosis method described in the first aspect or any corresponding embodiment thereof. Attached Figure Description

[0037] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0038] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this disclosure; Figure 2 This is a schematic flowchart of a first method for diagnosing network faults according to an embodiment of the present disclosure; Figure 3 This is a schematic diagram of a second process for a network fault diagnosis method according to an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the overall process of terminal network perception and fault delimitation according to an embodiment of this disclosure; Figure 5 This is a schematic diagram of a boot screen showing a fault type of "network unavailable" or "no network connection" according to an embodiment of the present disclosure. Figure 6 This is a schematic diagram of a boot screen indicating a VPN startup failure type according to an embodiment of the present disclosure. Figure 7 This is a schematic diagram of the boot screen for a network proxy failure according to an embodiment of the present disclosure; Figure 8 This is a schematic diagram of the boot interface when the fault type is illegal DNS according to an embodiment of this disclosure; Figure 9 This is a schematic diagram of a boot screen showing a domain name resolution error according to an embodiment of the present disclosure. Figure 10 This is a schematic diagram of a boot screen for a fault type of poor network quality according to an embodiment of the present disclosure. Figure 11 This is a schematic diagram of a normal network boot interface according to an embodiment of the present disclosure; Figure 12 This is a structural block diagram of a network fault diagnosis device according to an embodiment of the present disclosure; Figure 13 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0040] It should be noted that the information (including but not limited to user input information, such as information entered into input boxes), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, service pressure corresponding to operations performed on all code of the current project, and code development status of the current project), and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, the corresponding service pressure, and code development status involved in this disclosure were all obtained with full authorization.

[0041] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this disclosure, "a plurality of" means two or more, unless otherwise expressly specified.

[0042] Before providing a detailed description of the embodiments of this disclosure, some of the nouns and terms involved in the embodiments of this disclosure will be explained.

[0043] (1) Terminal devices: refers to hardware devices with network connectivity used by users, such as smartphones, and also includes tablets, laptops and IoT devices.

[0044] (2) Network awareness: refers to the entire process by which terminal devices monitor, collect, and analyze current network environment parameters in real time through lightweight proxy programs. The objects collected include signal physical characteristics, link quality, and connection status.

[0045] (3) Fault delimitation: This refers to the process of accurately locating the responsible party and the location of a network problem through logical analysis based on the perceived data. That is, distinguishing whether the fault originates from user equipment settings, LAN / router, operator network, or remote server.

[0046] (4) Rule engine: refers to a set of logical rules that run on the terminal or in the cloud, containing predefined judgment conditions. When the input data meets specific conditions, the engine automatically outputs the corresponding conclusion.

[0047] (5) RSSI (Received Signal Strength Indicator): A key indicator used to measure the physical coverage quality of wireless signals (such as Wi-Fi or cellular networks), usually measured in dBm.

[0048] (6) VPN (Virtual Private Network): In network diagnostics, enabling a VPN usually changes the data transmission path, which may lead to increased latency or connection interruption. It is a high-priority investigation target.

[0049] (7) DNS (Domain Name System): responsible for converting website addresses into IP addresses.

[0050] (8) LocalDNS: Local DNS server automatically assigned by the operator or router.

[0051] (9) HttpDNS: A resolution request sent directly to an authoritative DNS server via the HTTP protocol.

[0052] (10) DNS poisoning / blacklist: refers to DNS resolution being directed to malicious, invalid or geographically distant servers (such as overseas DNS configured within the country), resulting in slow access.

[0053] (11) Gateway and DHCP: The gateway is the exit point for a device to the external network. Missing gateway information usually means that DHCP (Dynamic Host Configuration Protocol) has failed, that is, the device is connected to the router but has failed to obtain a valid IP address.

[0054] (12) APP network speed: refers to the actual traffic throughput of the target application in the foreground within a unit of time.

[0055] (13) Global network speed: refers to the total traffic throughput of all background processes and foreground applications at the operating system level.

[0056] (14) CDN (Content Delivery Network): Ping CDN nodes are used to detect the connectivity of a specific application content server.

[0057] (15) Wi-Fi rate limiting: Specifically refers to the practice in an enterprise or local area network where the administrator uses firewall policies to prevent certain types of applications (such as video and games) from accessing the network, which is manifested by the network layer returning specific error codes.

[0058] As one optional application scenario of this disclosure embodiment, such as Figure 1 As shown, this network fault diagnosis method can be implemented in a system that includes at least one terminal device and at least one server. Figure 1 The example illustrates that the system includes a computer 101, a mobile terminal 102, and a server 103, and terminal devices such as the computer 101 and mobile terminal 102 are connected to the server 103 via a network 110. In this scenario, the terminal devices (such as the mobile terminal 102) can execute the network fault diagnosis method provided in this embodiment to diagnose the process of connecting to the network 110.

[0059] The terminal devices can specifically be smartphones, tablets, laptops, PDAs, desktop computers, game consoles, smart TVs, smart wearable devices, in-vehicle terminals, VR (Virtual Reality) devices, AR (Augmented Reality) devices, etc. These devices all have network connectivity and may encounter network failures. Server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranets, local area networks, wide area networks, mobile communication networks, and combinations thereof.

[0060] In related technologies, when users encounter problems such as network lag, inability to connect, or slow access when using terminal devices, existing network diagnostic tools often only provide a single speed test value or a simple connectivity test result (such as Ping value). This addresses the challenges users face in complex network environments, including unclear fault location, high difficulty in troubleshooting, and the inability to accurately distinguish between device configuration errors and external network quality anomalies. This disclosure provides a network fault diagnosis method. This method acquires multi-dimensional network status data covering device configuration and network performance, utilizes a pre-built fault feature library, and strictly performs feature matching analysis on the data according to preset detection priorities. Based on the analysis results, it determines the specific type of network fault, achieving the technical effect of comprehensively perceiving the terminal network environment and automatically and accurately identifying the root cause of network faults.

[0061] According to an embodiment of this disclosure, a network fault diagnosis method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0062] This embodiment provides a network fault diagnosis method, which can be used in the aforementioned terminal devices, such as mobile phones and tablets. Its application scenarios can also include relay devices (such as routers, gateways, and switches) in network links, or backend servers. Figure 2 This is a flowchart of a network fault diagnosis method according to an embodiment of the present disclosure, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain network status data.

[0063] Network status data refers to a collection of parameters and information used to characterize the current network connection environment, link transmission quality, and device network configuration attributes.

[0064] In this embodiment, network status data can be not only signal strength, assigned IP address, network latency, real-time throughput bandwidth, etc. collected by the terminal device itself, but also data from the relay device side, such as port congestion logs of the router, or data from the server side, such as client connection rejection rate recorded by the server.

[0065] The action of "acquiring" refers to the process of collecting and extracting required data through means such as calling software and hardware interfaces, passively listening, actively sending probe packets, or reading logs. For example, one can obtain the IP address assigned to the current device by calling the public API (Application Programming Interface) of the mobile terminal operating system; or obtain traffic statistics by listening to the number of bytes sent and received by the network card.

[0066] In this step, the executing entity (such as a terminal device or server) will initiate a data collection mechanism to comprehensively collect basic data for subsequent diagnostic analysis. For example, when a mobile phone user experiences network lag and initiates a diagnostic, the system will obtain the phone's current Wi-Fi signal strength, the latency in milliseconds obtained by sending Ping probe packets to specific network nodes, and simultaneously attempt to obtain channel status information fed back by relay devices (routers) within the local area network.

[0067] Step S202: Based on the fault feature library, perform feature matching analysis on the network status data according to the detection logic to obtain the feature matching analysis results.

[0068] A fault signature database refers to a database or set of rules pre-stored on a terminal or in the cloud, containing various known network fault modes and their corresponding judgment conditions. Rules in this database typically exist in the form of "IF-THEN". For example, the database includes, but is not limited to, the following rules: Rule 1: If `VPN status` is "enabled", the characteristic is "VPN proxy interference"; Rule 2: If the IP address of `dns_server` exists in the list of malicious DNS addresses, then the characteristic is "malicious DNS configuration"; Rule 3: If `wifi_signal_strength` is below -85dBm, the characteristic is "weak coverage with no signal". Rule 4: If `gateway_ip` is "empty" or "0.0.0.0", the characteristic is "gateway acquisition failed"; Rule 5: If `app_speed` < 300 KB / s and `global_speed` > 600 KB / s, then the characteristic is "bandwidth is being used by other applications".

[0069] The detection logic refers to the order of checks, priority relationships, or conditional branching paths followed when processing data. For example, it might prioritize checking whether the physical network card is enabled before checking the software-level proxy settings.

[0070] Feature matching analysis results refer to the intermediate state obtained after performing the operation (e.g., hitting a rule or not hitting it).

[0071] "Performing feature matching analysis" refers to the specific execution process of substituting the actual data collected in step S201 into the above rules for conditional judgment and logical operation. For example, the actual obtained Wi-Fi signal strength value is substituted into rule 3 above for comparison. If the condition is met, a label that matches the abnormal feature is obtained.

[0072] In this step, based on certain detection logic (e.g., prioritizing the investigation of local network settings and then network performance), the data obtained in step S201 is placed into the feature library for layer-by-layer fine-grained comparison.

[0073] For example, in the specific execution process, the current device's network configuration data is first parsed, and the highest priority rule 1 is retrieved for feature matching analysis. It is found that the VPN status is "off," so the condition is not met, and the process automatically moves down to the next rule. Then, performance-related rules are retrieved, extracting that the current network speed of a music app is 150 KB / s (i.e., app_speed), while the system's global network speed is 800 KB / s (i.e., global_speed). At this point, these two real-time extracted values ​​are substituted into rule 5 for condition evaluation. Logical calculations determine that both conditions are met (150 < 300 and 800 > 600), and the match is deemed true. Thus, the feature matching analysis result of "bandwidth being occupied by other applications" is successfully obtained, and based on the detection logic settings, subsequent invalid comparisons of lower priority rules can be stopped.

[0074] Step S203: Determine the network fault type based on the feature matching analysis results.

[0075] Network fault types refer to the final classification and characterization of the root cause of network problems, used to inform users of the nature of the problem. For example, fault types may include "device configuration errors" (such as accidentally turning on airplane mode), "network interference faults" (such as VPN causing slowness), "LAN infrastructure faults" (such as router failing to assign IP addresses), or "network resource contention" (such as background downloads competing for bandwidth).

[0076] The "determine" action refers to the decision-making process of mapping the vague "poor network" to a specific fault category based on the matched features.

[0077] In this step, one or more feature matching analysis results output in step S202 are comprehensively evaluated to pinpoint the root cause of the network anomaly. For example, if the feature matching analysis result obtained in step 202 is "malicious DNS configuration," then the current network fault type is determined to be a device network configuration fault caused by an abnormal domain name resolution service, thereby guiding the user to modify the correct DNS address.

[0078] In summary, the network fault diagnosis method provided in this disclosure provides an objective data foundation for subsequent fault analysis by acquiring network status data; based on a fault feature library, feature matching analysis is performed on the network status data according to detection logic, which can systematically compare discrete network data with known fault modes to obtain accurate feature matching analysis results; furthermore, the network fault type is determined based on the feature matching analysis results, realizing the effect of automated processing of network data and accurate location of fault types, thereby helping to quickly and accurately diagnose network faults and improving the efficiency and accuracy of network fault handling.

[0079] This embodiment provides a network fault diagnosis method, which can be used in the aforementioned terminal devices, such as mobile phones and tablets. Its application scenarios can also include relay devices (such as routers, gateways, and switches) in network links, or backend servers. Figure 3 This is a flowchart of a network fault diagnosis method according to an embodiment of the present disclosure, such as... Figure 3 As shown, the process includes the following steps: Step S301: Obtain network status data.

[0080] To gain a more comprehensive understanding of network conditions, the network status data in this embodiment further includes device configuration parameters and network performance indicators.

[0081] Device configuration parameters refer to software settings that affect network connectivity. Specifically, they include: Virtual Private Network Status: This indicates whether the device has established a VPN tunnel. For example, whether the user has enabled a VPN client for remote work.

[0082] Network proxy status: This indicates whether a network request has passed through an intermediate proxy server. For example, whether an HTTP proxy is manually configured in the Wi-Fi settings.

[0083] Domain Name System (DNS) server address: This refers to the IP address of the DNS server used by the current network connection. For example, is it the LocalDNS provided by the ISP by default, or is it 8.8.8.8 that the user manually changed?

[0084] Gateway address acquisition status: This indicates whether the device has successfully obtained the gateway IP address from the router's DHCP service. For example, whether it remains in the "Obtaining IP address" stage after connecting to Wi-Fi.

[0085] Network performance parameters are dynamic indicators that reflect the quality of data transmission. Specifically, they include: Target application traffic rate: refers to the download / upload speed of a specific application (such as video software) that the user is currently using.

[0086] Terminal global traffic rate: refers to the total throughput of all processes on the entire terminal device.

[0087] In addition, network status data can also include application network request logs. This refers to the underlying log data generated by the application during network communication. For example, specific HTTP status codes (such as 403 Forbidden) or TCP error codes (such as RST) can be extracted from the logs for subsequent analysis to determine if specific access restrictions exist.

[0088] Step S302: Based on the fault feature library, perform feature matching analysis on the network status data according to the detection logic to obtain the feature matching analysis results.

[0089] To ensure the logical rigor and execution efficiency of the matching analysis, the detection logic, in descending order of diagnostic level, includes: physical network connection and application permission check level; device network configuration parameter check level; LAN gateway connectivity check level; network traffic congestion analysis level; and remote node connectivity check level. If a fault is identified at a higher priority level, the feature matching analysis at the lower priority level is stopped.

[0090] For example, if a VPN is detected causing anomalies at the second layer (device network configuration), subsequent speed tests and remote ping tests will be stopped. This not only makes the diagnostic process more organized but also greatly reduces unnecessary computational overhead in the diagnostic process.

[0091] To improve analysis efficiency and avoid unnecessary calculations, a preliminary detection step is included before formal feature matching analysis: detecting the physical network connectivity status and the network permission status of the target application. The physical network connectivity status refers to hardware-level connectivity, such as whether Wi-Fi is on or airplane mode is off; network permission status refers to the operating system's restrictions on data usage by specific applications, such as prohibiting an application from using cellular data in iOS (Apple's mobile operating system).

[0092] If a physical network connection is detected as disconnected (e.g., airplane mode is enabled), a physical connection failure is directly identified. If the physical connection is normal, but network access permission is detected as prohibited, an application permission failure is directly identified.

[0093] This preliminary step can quickly intercept the most basic user error issues (such as forgetting to turn on the network), avoiding subsequent complex packet detection and saving resources and time.

[0094] After passing the preliminary checks, the core analysis phase will begin. The preset check priority follows a logic of configuration first, then performance, specifically including: Step S3021: First, perform feature matching analysis on the device configuration parameters related to device configuration in the network status data to identify whether there are any device configuration-related faults.

[0095] Configuration errors (such as accidentally enabling a proxy) are a high-frequency and disruptive human factor that can cause network unavailability and should be investigated first.

[0096] The identification logic for device configuration-related faults is as follows: Device configuration parameters include network proxy and routing configuration parameters, which further include virtual private network status, network proxy status, DNS server address, and gateway address acquisition status. A device configuration fault is determined to exist when any of the following conditions are detected: The Virtual Private Network is enabled (which may result in route detours or being blocked). The network proxy is enabled (the proxy server is unstable). The currently used Domain Name System (DNS) server address exists in the preset list of abnormal DNS systems (which may lead to DNS hijacking or slow resolution). Unable to obtain a valid gateway address (i.e., DHCP failed, which is a configuration problem at the LAN connection level).

[0097] The Domain Name System (DNS) server address refers to the DNS configuration information currently used by the terminal to resolve domain names to IP addresses. The abnormal DNS list refers to a pre-configured and stored set of DNS server IP addresses known to cause network resolution instability, service unavailability, or security risks.

[0098] This list of anomalous DNS systems typically includes a list of known DNS servers with resolution risks, as well as a list of non-local DNS servers maintained by the system itself (e.g., DNS addresses unavailable across regions due to user misconfiguration, such as "4.2.2.2"). This list is usually centrally maintained in the cloud. This means that security and resolution rules are dynamically updated, and diagnostic agents on end devices only need to periodically pull the latest list file from the cloud to maintain their ability to identify new network resolution anomalies.

[0099] This can accurately identify network problems caused by users modifying settings without authorization (such as enabling VPN or changing DNS) or by abnormal local area network infrastructure (routing allocation failure), clearly attributing the problem to the configuration level rather than the operator's network quality.

[0100] Step S3022: If no device configuration fault is identified, feature matching analysis is performed on the network performance indicators related to network performance in the network status data to identify whether there is a network performance fault.

[0101] If no configuration anomalies are found in the above checks, then proceed to performance-related checks. Specifically, generate a first analysis result based on network performance metrics; based on the first analysis result, determine the specific type of network performance fault.

[0102] This hierarchical diagnostic logic ensures that pseudo-network faults (caused by misconfiguration) are identified first. For example, if a user is unable to access the internet due to enabling the wrong proxy server, the system will directly report a configuration error instead of performing time-consuming speed tests or ping operations, thus significantly improving the accuracy and response speed of fault localization.

[0103] Network performance metrics include target application traffic rate and global traffic rate. Target application traffic rate refers to the network speed of a single app currently experiencing a problem (such as a music app); global traffic rate refers to the network throughput of the entire system's network ports.

[0104] The first analysis result is generated based on network performance metrics, and the specific logic is as follows: First, determine the relationship between the target application traffic rate and the first preset threshold, and the relationship between the global traffic rate and the second preset threshold, and generate traffic analysis results. The first analysis result includes the traffic analysis results, and the first preset threshold is less than the second preset threshold.

[0105] When comparing traffic rates, the first and second preset thresholds are mainly used to define the critical point between single-application lag and network smoothness. The setting logic of these two thresholds combines basic standards with dynamic flexibility, and their baseline values ​​can be set based on the statistical results of a large amount of end-user experience data (for example, the first preset threshold is set to 300k / s by default, and the second preset threshold is set to 600k / s by default).

[0106] Furthermore, to ensure the accuracy of the diagnosis, these thresholds can be dynamically adjusted based on the type of application currently running in the foreground or the type of network currently connected (such as Wi-Fi or cellular data). For example, for real-time competitive games with frequent data interactions and extremely high latency requirements, the threshold standards may be set higher to more sensitively detect even minor network degradation; while for information browsing applications that only load static text and lightweight images, the threshold standards can be adjusted accordingly.

[0107] In another, more specific implementation scenario, if it is detected that a user is currently using a high-definition video streaming application, in order to match the minimum smooth playback requirements of this service type, the first preset threshold can be dynamically increased to 500KB / s, and the second preset threshold can be set to 1MB / s. Through this service scenario-aware dynamic threshold setting logic, it is possible to quantify and determine with extremely high precision whether the current network can support the normal operation of a specific application.

[0108] To ensure lightweight computation, the global traffic rate is obtained as follows: within a preset time interval, the difference between the total traffic statistics of the operating system is obtained; based on the difference and the preset time interval, the global traffic rate is calculated.

[0109] Another performance measurement method involves sending probe packets to multiple network nodes to obtain node connectivity analysis results. The first analysis result includes the node connectivity analysis results. Probe packets are such as ICMP Ping packets. Packets are sent and return packet latency or packet loss rate is calculated to evaluate the link. Specifically, the multiple network nodes include content delivery network nodes and public network reference nodes; the node connectivity analysis results include the connectivity status of content delivery network nodes and the connectivity status of public network reference nodes. Content delivery network nodes (CDN nodes) represent the edge servers of the service itself, and public network reference nodes represent general internet benchmarks.

[0110] Based on the above analysis, further fault delimitation can be performed: Bandwidth occupancy fault: When traffic analysis results indicate that the target application's traffic rate is less than or equal to a first preset threshold (slow application), but the overall traffic rate is greater than a second preset threshold (fast overall phone speed), the specific type is determined to be a bandwidth occupancy fault. For example, a user experiences lag while playing a game (low application speed), but at the same time, the phone is downloading a system update at high speed in the background (high overall speed). This logic solves the classic problem of "fast speed test but laggy experience," accurately pointing out the root cause of background resource competition.

[0111] Network link quality failure: When traffic analysis results indicate that the target application's traffic rate is less than or equal to a first preset threshold, and the global traffic rate is also less than or equal to a second preset threshold, the specific type is determined to include network link quality failure. This means that the physical pipeline itself is narrow or congested.

[0112] Node access quality failure: When the connectivity status of a content delivery network node is abnormal (e.g., high packet loss when pinging the CDN), but the connectivity status of the public network reference node is normal (normal pinging of the public network reference node), the specific type is identified as a node access quality failure. This indicates that internet access is good, and the problem lies with the server of a specific application or the CDN provider, helping users troubleshoot their own broadband issues.

[0113] Network link connectivity failure: When an abnormal connectivity status is detected in the public network reference node, the specific type is determined to be a network link connectivity failure. This usually means a carrier network outage or fiber optic cable failure.

[0114] In addition, for certain special network environments, network status data also includes application network request logs. During analysis, the status codes returned by network requests are extracted from these logs, and the consecutive occurrences of preset specific error codes are counted. When the consecutive occurrences exceed a preset security threshold, the network fault type is determined to include wireless LAN access restriction faults (i.e., Wi-Fi rate limiting or firewall blocking). Specific error codes include HTTP request rejection indicators. For example, preset specific error codes include the HTTP 403 Forbidden code.

[0115] Here, the predefined specific error code specifically refers to the protocol status code returned by network intermediate devices (such as corporate firewalls, public network gateways, etc.) to indicate that access has been policy-denied. In actual network communication interactions, such error codes commonly include the HTTP protocol's 403 (Forbidden) status code, 407 (Proxy authentication required) status code, and the TCP protocol layer's Connection Reset (RST) flag, etc.

[0116] Meanwhile, to effectively filter extremely short-term network fluctuations, a security threshold mechanism is introduced. The core logic of setting the security threshold lies in determining whether the aforementioned errors are persistent and strategically occurring, rather than caused by accidental network jitter. The specific value is typically set by comprehensively considering the length of the detection time window and the severity of the error. Specifically, it involves counting the number of times a pre-defined specific error code appears continuously in the application's network request logs. For example, specific errors are continuously counted in the background; a time window can be set (e.g., observing network requests within the last 30 seconds), and the occurrence of three consecutive identical specific error codes is considered to have reached the security threshold. Only when application-level access denial errors reach this persistent standard will a final judgment be made and a conclusion such as "entertainment applications are blocked on the company intranet" (i.e., Wi-Fi throttling) be output. This statistical judgment method using security thresholds greatly enhances the fault tolerance rate and reliability of the diagnosis. This can identify strategic blocking of specific entertainment applications on the enterprise intranet or LAN, avoiding misjudging it as poor network signal and informing users that this is a management policy rather than a technical fault.

[0117] Step S303: Determine the network fault type based on the feature matching analysis results.

[0118] After determining the network fault type of the terminal device, this embodiment can also match the corresponding repair strategy from the preset solution knowledge base according to the determined network fault type, and generate repair guidance instructions based on the repair strategy.

[0119] In this step, the solution knowledge base is a pre-stored set of troubleshooting strategy maps. Repair strategies are specific solutions for particular faults (such as disabling the VPN, switching to a mobile network, or pausing background downloads). "Repair guides" are interactive elements displayed on the interface, such as text prompts or buttons that directly jump to the settings page.

[0120] For example, if the fault type is determined to be "Device configuration fault (VPN enabled)," the matched policy is "Disable VPN," and a repair guide is generated stating, "VPN is detected. Please disable VPN and try again." If the fault is classified as "Bandwidth usage fault," the user is guided to clear background applications. This allows users to restore their network without needing professional knowledge or searching for solutions themselves; they simply need to follow the guide to significantly improve the user experience.

[0121] In summary, the network fault diagnosis method provided in this embodiment firstly overcomes the limitations of related technologies that rely solely on a single indicator for evaluation by collaboratively collecting multi-dimensional data such as device configuration parameters, network performance parameters, and application logs, ensuring comprehensive fault perception. Secondly, by introducing a hierarchical detection priority logic (physical permissions first, then device configuration, and finally network performance), it achieves efficient filtering for fault diagnosis, avoiding invalid performance tests caused by incorrect basic settings, and accurately locating the root cause of faults in complex scenarios through refined traffic and node comparison logic. Furthermore, this method incorporates specific log analysis to identify hidden access restriction issues, and finally transforms the technical fault delimitation results into user-executable repair instructions through a solution knowledge base. This method not only significantly improves the accuracy and efficiency of network fault delimitation but also greatly reduces the professional threshold and time cost for ordinary users to troubleshoot network problems.

[0122] To better illustrate the network fault diagnosis method of the embodiments, a preferred embodiment will be provided below. This embodiment is intended to describe the implementation process of this disclosure in detail, but is not intended to limit the scope of protection of this disclosure.

[0123] This preferred embodiment deploys a lightweight diagnostic agent on the user terminal (such as a smartphone) and works with a cloud-based or local rule engine to achieve a fully automated process from data collection and logical analysis to fault localization and guided repair.

[0124] This embodiment provides a terminal network awareness and fault localization method. This method deploys an intelligent agent on the terminal device side, combined with a cloud-based or local rule engine, to achieve automated detection, localization, and repair guidance for network faults. This embodiment covers the complete process from data collection and logical analysis to end-user interaction.

[0125] This embodiment first performs multi-dimensional collaborative data collection.

[0126] When a user experiences network lag, connection failure, or initiates a diagnostic, the lightweight agent deployed on the terminal device first activates the data collection mechanism. To comprehensively reconstruct the network situation, the system collects data from the following four dimensions: Basic network parameters include the current RSSI signal strength, the device's local IP address, and the LocalDNS server address. The system will also attempt to obtain the HttpDNS resolution results for subsequent data comparison and analysis.

[0127] Network performance parameters: Execute the Ping command to obtain network latency (RTT) and packet loss rate; calculate the real-time bandwidth rate of the current target application; and, under non-root privileges, calculate the device's global network speed by statistically analyzing the system traffic difference over a short period of time (such as before and after 5 seconds).

[0128] Device environment parameters: Read the application's network request logs (for error code analysis), and record the geographical location, current network type (Wi-Fi or mobile data), and timestamp.

[0129] Configure status parameters: Check whether the VPN is enabled, whether the network proxy is configured, and the network access permission status of the application.

[0130] This is followed by priority-based fault delimitation.

[0131] The collected data is fed into the built-in rule engine. To improve diagnostic efficiency, this embodiment uses feature matching in descending priority order. The overall process of terminal network perception and fault localization is as follows: Figure 4 As shown, a strict detection priority is set based on the probability of failure and the cost of troubleshooting. Once a problem is found and resolved at a previous node, subsequent detection stops. The specific process is as follows: The first level of diagnosis involves checking physical connections and permissions.

[0132] First, check the device's physical network status. If the device is found to be in airplane mode or with Wi-Fi or mobile data switched off (i.e., no network), it is determined to be a physical connection failure, and the user should be directly guided to enable a network connection. Figure 5 As shown, Figure 5 This is the boot screen for fault types such as network unavailable or no network connection.

[0133] If the physical network is normal, further check the application permissions at the operating system level. For example, in iOS, check if the target application has cellular data permission disabled. If permission is disabled, it is determined to be an application permission failure, and guide the user to go to system settings to enable permission.

[0134] The second level of diagnosis is a device configuration check. If network connectivity and permissions are normal, the rule engine proceeds to check the configuration level: The system checks if the device has a VPN enabled or a network proxy configured. Since these configurations often cause routing issues or bandwidth bottlenecks, if the VPN is detected as enabled, it's considered a configuration-related fault, and a guidance screen will pop up suggesting the user disable the VPN or network proxy. Figure 6 and Figure 7 As shown, Figure 6 This is the boot screen for a VPN-type fault. Figure 7 This is the boot screen for a fault type of "network proxy".

[0135] The system compares the currently used DNS address with a pre-configured cloud-based malicious DNS blacklist. If a match is found, it indicates a DNS configuration error, and the user is guided to modify or reset their DNS settings. Figure 8 and Figure 9 As shown, Figure 8 This is the boot screen for an invalid DNS fault. Figure 9 This is the boot screen for a fault type of domain name resolution error.

[0136] The third level of diagnosis is a local area network (LAN) environment check.

[0137] Check if the device has successfully obtained a gateway IP address. If the IP address is missing (usually indicating a problem with the router's DHCP service), the issue is considered a gateway information missing fault. If the current environment is Wi-Fi, guide the user to restart the router; if the current environment is mobile data, guide the user to reset the data switch.

[0138] The fourth level of diagnosis is traffic congestion and speed-hogging analysis. If there are no abnormalities in configuration and connection, but the user still feels that the network speed is slow, an in-depth traffic characteristic analysis will be performed to distinguish whether the slowness is genuine or due to speed-hogging.

[0139] The rules engine reads the app's network speed and the global network speed, and compares them with preset thresholds (for example, the threshold for the app's network speed is set to 300KB / s, and the threshold for the global network speed is set to 600KB / s).

[0140] If the app's network speed is detected to be less than or equal to 300KB / s (slow app) but the overall network speed is greater than 600KB / s (fast device overall), it is inferred that other background programs (such as system updates or cloud storage downloads) are consuming bandwidth. In this case, it is determined to be a bandwidth occupancy problem, and the user is guided to clear background applications.

[0141] If the overall network speed is less than or equal to 600KB / s, it indicates that the overall network quality of the device is poor. In this case, it is further determined to be a global weak network, the poor network quality is recorded, and the user is guided to switch networks (such as from Wi-Fi to mobile data) or move their location.

[0142] The fifth level of diagnosis involves checking node connectivity and policies. If none of the above checks reveal any anomalies, the problem lies deeper in the network links or on the server side. Perform a layered Ping test: Ping the target app's CDN server and the public network reference node.

[0143] If the CDN is unavailable but the public network anchor point is available: it is determined that the APP's server or CDN node is faulty, and the user is prompted that the application server is abnormal.

[0144] If both are unreachable or the network is weak: the current network quality is considered poor. Figure 10 As shown, Figure 10 This is the boot screen for a fault type of poor network quality. The problem may stem from poor signal coverage (low RSSI) or congestion on the carrier's backbone network.

[0145] For such physical link issues, guide users to switch networks (e.g., from Wi-Fi to cellular data) or move to a location with better signal.

[0146] As a supplementary process, this embodiment will also continuously collect specific error codes (such as HTTP 403 Forbidden or TCP connection reset) from the application network request logs. If the number of consecutive occurrences of such error codes exceeds a preset threshold, the rule engine will identify it as a Wi-Fi rate limiting feature. This indicates that the network is not malfunctioning, but is restricted by administrator policies (such as prohibiting video streaming during working hours), thereby preventing users from falsely reporting a fault.

[0147] Based on the final fault type determined by the above analysis, the user interface module will retrieve the corresponding text and operation instructions from the solution knowledge base and display them intuitively to the user: For configuration-related issues: the user interface will display a corresponding guide. If an unauthorized DNS or VPN is detected, the interface will display a message such as "An unavailable DNS has been detected" or "A VPN has been detected" in a pop-up window or on a separate page. Simultaneously, the interface will provide a "Go to Settings" button. Responding to user touch of this button, the terminal device will automatically redirect to the corresponding network settings or VPN settings interface within the operating system, allowing the user to directly view and modify the relevant configurations.

[0148] Network quality issues: If a weak network or abnormal node is detected, indicating "poor network environment" or "unstable network access", it is recommended to switch networks.

[0149] Normal state: If no abnormalities are found in any of the tests, the "No abnormalities found in the diagnosis" page will be displayed, and the user will be allowed to click the feedback button. Figure 11 As shown, Figure 11 This is the normal network setup interface.

[0150] In summary, this embodiment achieves automation and efficiency in network fault diagnosis through multi-dimensional data collection and autonomous analysis, reducing manual intervention and significantly improving customer complaint handling efficiency. Its feature-rule-based multi-parameter analysis significantly improves the accuracy of fault location and reduces the false positive rate. Simultaneously, the solution boasts excellent user-friendliness, translating technical parameters into easily understandable solutions, enabling users to independently repair network problems.

[0151] This embodiment also provides a network fault diagnosis device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0152] This embodiment provides a network fault diagnosis device, such as... Figure 12 As shown, it includes: Module 1201 is used to acquire network status data; Analysis module 1202 is used to perform feature matching analysis on network status data based on the fault feature library and according to the detection logic to obtain feature matching analysis results; The determination module 1203 is used to determine the network fault type based on the feature matching analysis results.

[0153] In one optional implementation, the network fault type includes at least one of device configuration faults and network performance faults; the analysis module 1202 is used for: First, perform feature matching analysis on the device configuration parameters related to device configuration in the network status data to identify whether there are device configuration-related faults. If no device configuration-related faults are identified, feature matching analysis is performed on network performance indicators related to network performance in the network status data to identify whether network performance-related faults exist.

[0154] In one alternative implementation, the device configuration parameters include network proxy and routing configuration parameters.

[0155] In one optional implementation, the network proxy and routing configuration parameters include the virtual private network status; the analysis module 1202 is used for: When a virtual private network is detected to be enabled, a device configuration fault is identified.

[0156] In one optional implementation, the network proxy and routing configuration parameters include the network proxy status; the analysis module 1202 is used for: When a network proxy is detected to be enabled, a device configuration fault is identified.

[0157] In one optional implementation, the network proxy and routing configuration parameters include the Domain Name System (DNS) server address; the analysis module 1202 is used for: When the address of the currently used Domain Name System (DNS) server is detected to exist in the preset list of abnormal DNS systems, a device configuration fault is determined to exist.

[0158] In one optional implementation, the network proxy and routing configuration parameters include gateway address acquisition status; the analysis module 1202 is used for: When a valid gateway address cannot be obtained, a device configuration fault is identified.

[0159] In one alternative implementation, the analysis module 1202 is used for: The first analysis result is generated based on network performance metrics; Based on the initial analysis results, the specific types of network performance failures were determined.

[0160] In one optional implementation, network performance metrics include target application traffic rate and global traffic rate; analysis module 1202 is used for: The relationship between the target application traffic rate and a first preset threshold, and the relationship between the global traffic rate and a second preset threshold are determined to generate traffic analysis results. The first analysis result includes the traffic analysis results; wherein the first preset threshold is less than the second preset threshold.

[0161] In one alternative implementation, the analysis module 1202 is used for: Within a preset time interval, obtain the difference between the total traffic statistics of the operating system; The global flow rate is calculated based on the difference and the preset time interval.

[0162] In one alternative implementation, the analysis module 1202 is used for: When the traffic analysis results indicate that the target application's traffic rate is less than or equal to the first preset threshold, and the global traffic rate is greater than the second preset threshold, the specific type is determined to include bandwidth occupancy fault. When the traffic analysis results indicate that the target application traffic rate is less than or equal to a first preset threshold, and the global traffic rate is less than or equal to a second preset threshold, the specific type is determined to include network link quality failure.

[0163] In one alternative implementation, the analysis module 1202 is used for: Probe data packets are sent to multiple network nodes to obtain node connectivity analysis results. The first analysis result includes the node connectivity analysis results.

[0164] In one optional implementation, the multiple network nodes include content delivery network nodes and public network reference nodes; the node connectivity analysis results include the connectivity status of the content delivery network nodes and the connectivity status of the public network reference nodes.

[0165] In one alternative implementation, the analysis module 1202 is used for: When the connectivity status of a content delivery network node is abnormal, while the connectivity status of a public network reference node is normal, the specific type is determined to include node access quality failure. When the connectivity status of the public network reference node is abnormal, the specific type is determined, including network link connectivity failure.

[0166] In one optional implementation, the detection logic includes, in descending order of diagnostic level: Physical network connectivity and application permission check hierarchy; Device network configuration parameter check level; Local area network gateway connectivity check level; Network traffic congestion analysis hierarchy; And the remote node connectivity check hierarchy; If a fault is identified at a higher priority level, the feature matching analysis at a lower priority level will be stopped.

[0167] In an optional implementation, the network status data further includes application network request logs; the determination module 1203 is used for: Extract the status codes returned by network requests from the application's network request logs; Count the number of consecutive occurrences of a specific pre-defined error code in the status codes; When the number of consecutive occurrences exceeds the preset safety threshold, the network fault type is determined to include wireless LAN access restriction fault.

[0168] In one optional implementation, the preset specific error code includes the 403 Forbidden code in the HTTP protocol; Count the number of consecutive occurrences, including: counting the number of times a specific preset error code appears continuously in the application's network request log.

[0169] In an optional implementation, the analysis module 1202 is further configured to: Detect the physical network connectivity status and the network permission status of the target application; If the physical network connection status is disconnected, it is determined that there is a physical connection failure; If the physical network connection status is connected and the network access permission status is prohibited, then an application permission failure is determined.

[0170] In one alternative implementation, the determining module 1203 is further configured to: Based on the identified network fault type, the corresponding repair strategy is matched from the preset solution knowledge base, and repair guidance instructions are generated based on the repair strategy.

[0171] The network fault diagnosis device provided in this disclosure can execute the network fault diagnosis method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0172] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure.

[0173] The following is a detailed reference. Figure 13 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 1301, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1302 or a program loaded from memory 1308 into random access memory (RAM) 1303. The RAM 1303 also stores various programs and data required for the operation of the electronic device. The processor 1301, ROM 1302, and RAM 1303 are interconnected via a bus 1304. An input / output (I / O) interface 1305 is also connected to the bus 1304.

[0174] Typically, the following devices can be connected to I / O interface 1305: input devices 1306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 1307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 1308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1309. Communication device 1309 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 13 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0175] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 1309, or installed from memory 1308, or installed from ROM 1302. When the computer program is executed by processor 1301, it performs the functions defined in the network fault diagnosis method of embodiments of this disclosure.

[0176] Figure 13The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0177] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code downloaded over a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code. When the software or computer code is accessed and executed by the computer, processor, or hardware, the network fault diagnosis method shown in the above embodiments is implemented.

[0178] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0179] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A network fault diagnosis method, characterized in that, The method includes: Obtain network status data; Based on the fault feature library, feature matching analysis is performed on the network state data according to the detection logic to obtain the feature matching analysis results; Based on the feature matching analysis results, the network fault type is determined.

2. The method according to claim 1, characterized in that, The network fault types include at least one of device configuration faults and network performance faults; the detection logic includes: First, feature matching analysis is performed on the device configuration parameters related to device configuration in the network status data to identify whether there are device configuration-related faults. If no device configuration-related faults are identified, feature matching analysis is performed on the network performance indicators related to network performance in the network status data to identify whether network performance-related faults exist.

3. The method according to claim 2, characterized in that, The device configuration parameters include network proxy and routing configuration parameters.

4. The method according to claim 3, characterized in that, The network proxy and routing configuration parameters include the virtual private network status; The identification of whether a device configuration-related fault exists includes: When a virtual private network is detected to be enabled, a device configuration fault is identified.

5. The method according to claim 3, characterized in that, The network proxy and routing configuration parameters include the network proxy status; The identification of whether a device configuration-related fault exists includes: When a network proxy is detected to be enabled, a device configuration fault is identified.

6. The method according to claim 3, characterized in that, The network proxy and routing configuration parameters include the Domain Name System (DNS) server address; The identification of whether a device configuration-related fault exists includes: When the address of the currently used Domain Name System (DNS) server is detected to exist in the preset list of abnormal DNS systems, a device configuration fault is determined to exist.

7. A network fault diagnosis device, characterized in that, The device includes: The acquisition module is used to acquire network status data; The analysis module is used to perform feature matching analysis on the network status data based on the fault feature library and according to the detection logic to obtain the feature matching analysis results; The determination module is used to determine the network fault type based on the feature matching analysis results.

8. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the network fault diagnosis method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the network fault diagnosis method according to any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions for causing a computer to perform the network fault diagnosis method according to any one of claims 1 to 6.

Images