There is a scientific Web debugging agent tool that is particularly important at the front end, which often requires a special debugging environment.
The first proxy I used was [Charles] (https://www.charlesproxy.com/), with multiple functions but obvious shortcomings, heavy, trouble-maker, crawling.
It was changed to [Zan Proxy] (https://github.com/youuzan/zan-proxy)
Zan Proxy is an agent tool written by Node.js that, unlike Charles, focuses on Web debugging, lightweight, easy to configure, which is simple, but it’s enough for me.
The configuration is done on a web page, the interface is comfortable, and I use it to make simple forward requests, modify response headers, mock data
[image] (./attachments/bafybeigvagrzrtsktce 5wnch25qm72mrw2rq2j2bcaml3pv4subuava.png)
But with the development of the work, the need for a debugging environment has become more complex.
[LightProxy]
LightProxy is a local proxy capture package based on (https://github.com/avwo/whistle) (~ it’s actually just about as direct as ~).
I’m going to introduce it by some of the rules I’m using.
** Request for transmission**
♪ Protected ♪
(1) Project interfaces and CDNs are restricted to certain domain names and therefore need such a development environment
More sserver with webpack to open an 80 port and hosts 80 times more elegant
(2) Available for proxy online files
Activate locally compiled project files to the real online environment, where the path is matched by wildcards
** Modified response**
♪ Protected ♪
Modify the response content of the mobile page so that the page can load the debugging tool, Eruda, to facilitate debugging the moving end
It’s worth mentioning that there’s a crazy place in which heistle doesn’t support in-line writing, and it’s difficult to set up {key} on another panel or use local files.
So LightProxy made a transition, saved the line code into a temporary file, opened the window and could see that the configuration actually sent to the window was similar.
♪ Protected ♪
Modified response head
♪ Protected ♪
Here’s a regular rule for matching different types of files.
** Change cookies**
♪ Protected ♪
It’s not so easy to change cookies on the move side, so I’m using this rule, which is essentially to modify the response head.
host forward
♪ Protected ♪
In addition to supporting a variety of matching models, there is support for traditional hospice syntax rules, which can be thrown away.
** Simulation network anomaly**
♪ Protected ♪
I’m in deep pain with all kinds of simulation network anomalies.
The example of <<PROTECTED_BLONK_9> matches the bilibili video CDN address
(1) Simulates a CDN status code to debug CDN addresses overtime or abnormal, without LightProxy only to mock in code or to wait very stupidly for video addresses over time
(2) Simulation slow speed, which is used to debug the carton or auto-resolution switch, which can be used in lieu of Chrome Network Trottling
(3) Simulation of CDN requests overtime, used to debug CDN pulls over time, without LightProxy, with careful control of the Chrome Network Trottling, too small to fail, too long and not long enough
** Node.js Rules**
LightProxy also has a cool function, using Node.js writing rules. Here’s an official demo. I don’t have a picture of this function yet, but it feels cool.
♪ PROTECTED ♪
From these examples, we believe that you have already understood the use of LightProxy / Whistle
And one last thing that is worth mentioning is, what happens when these debugging agent tools go online?
Debugging and magic on the Internet is a different agent. I’m a Google programr, and it’s too much of a problem. My system agent is handed over to Surge to take over, create a LightProxy agent using the Surge diversion, then edit the Surge rules, and only divide requests that need debugging to LightProxy.
[image] (./attachments/bafybeibx7ihnlfxsnqltmrml5arigikpkcsuey5q7u37ybzdapener7fwm.png)
This is my current Web debugging agent practice.