404 - Not Found error - 听云Network

Problem description:

In the basic page monitoring task of the customer account (xxx-self-built-xxx), the HTTP 404 page Error appeared 52 times in the past seven days. However, the HTTP 404 page Error did not appear in the comparison task (xxx-Tencent-xxx) bound with this task, and the customer did not find Log of the HTTP 404 type Error in Host. I hope to analyze whether it is a Probe quality problem.

Problem analysis process:

After receiving feedback on the problem, we first performed Instant Testing on Probe and found that the phenomenon could be reproduced. Probe, which previously reported 404Error, still reported HTTP 404Error when executing the task again, as shown below:

Then through packet capture data analysis, it was found that the server header value in the response was empty. As shown below:

It is confirmed that this is a Exception phenomenon. Since the specific cause cannot be determined for the time being, we first temporarily disabled Probe to avoid Probe from interfering with customer task data.
In order to further confirm the specific reason, we contacted the member of HTTP 404Error Probe and obtained the remote permission of the Probe. At this time, the URL in the task had begun to expire and an HTTP 403 error was reported. However, when accessing the Probe, an HTTP 404 error was still reported. As shown below:

We first started to check whether Probe has agent software turned on. No suspicious situation was found in the process of Synthetic Tasks, thus excluding Probe Host itself. As shown below:

After ruling out the problem of member Host itself, we investigated the member's local Network environment. Member computers dial up the Internet through a router. Exception was not found when logging into the router. As shown below:

We obtained each layer of routing through tracert. We can see that the IP address of the Host gateway is: 192.168.2.1 and the IP address of the upper layer routing is: 172.16.0.1 as shown below:

In order to test whether the task HTTP 404Error is caused by a problem with the member router, we first add a non-existent path to the Host gateway IP192.168.2.1 to access. Although the result is an HTTP 404, the HTTP 404 page here does not have a CSS style and a normal HTTP 404 response. As shown below:

From the above analysis, it can be seen that HTTP 404Error in the task has nothing to do with Probe itself Network (entry Network).
After further verification, we added a non-existent path to the IP 172.16.0.1 of the upper routing device and then accessed it. The response was also HTTP 404, but we found that the style of the HTTP 404 page had changed and was the same as the style in our task, as shown below:

It can be basically inferred that the HTTP 404 response received in the task was generated before logging in, because if the HTTP 404 was generated by the member Network device, this HTTP 404 cannot be styled.
When adding a custom HTTP header to sj1.kkmh.com.c.cdnhwc1.com (Huawei CDN-URL), the returned result is normal (HTTP 403). As shown below:

When the custom HTTP header is removed, the returned data is 404. As shown below:

From the above test results, we can infer the flow chart of HTTP 404Probe when accessing the target:

Probe Huawei task access process diagram

Simplified diagram of Probe access process after adding custom HTTP header sj1.kkmh.com.c.cdnhwc1.com

in conclusion:

The cause of the problem is that there is a reverse proxy in the operator Network. HTTP404 is actually responded by the proxy when it cannot parse the target URL, and has nothing to do with Probe's own Network environment. This phenomenon is a phenomenon that actually exists in the area where Probe is located, and is not a Probe problem.

Solution:

Do not use a custom Host but directly bind the CNAME

404 - Not Found error

Problem description:#

Problem analysis process:#

in conclusion:#

Solution:#

Problem description:

Problem analysis process:

in conclusion:

Solution: