Front-end often requires some special debugging environments, and a scientific web debugging proxy tool (referred to as a proxy tool) is particularly important in this case.
The first proxy tool I used is Charles. It has many features, but also has obvious disadvantages, such as being bulky and difficult to configure.
Later, I switched to Zan Proxy.
Zan Proxy is a proxy tool written in Node.js. It is different from the comprehensive tool Charles and focuses on web debugging. It is lightweight and easy to configure. Although its functionality is simple, it is sufficient for me.
All configurations are done on a web page, and the interface is very user-friendly. I use it to perform simple request forwarding, modify response headers, and mock data.
However, as the work content evolves, the debugging environments required become more and more complex, and Zan Proxy can no longer meet my needs.
LightProxy appeared in my sight at the right time.
LightProxy is a local proxy capture software based on whistle (actually, using whistle directly is almost the same).
Below are some rules I use to introduce it.
Request forwarding
player.bilibili.com http://127.0.0.1:8080
^*s1.hdslb.com/bfs/static/player/main/video*.js file:///Users/diygod/Code/bilibili/js-common/packages/video/dist/release/video.js
^*s1.hdslb.com/bfs/static/player/main/video*.js.map file:///Users/diygod/Code/bilibili/js-common/packages/video/dist/release/video.js.map
(1) Both project interfaces and CDNs are restricted to certain domain names, so we need something like this for development environments. It is more elegant than using webpack to open a server on port 80 and then bind hosts.
(2) It can be used to proxy online files. Proxy the locally compiled project files to the real online environment. Wildcards are used here to match paths.
Modify response content
m.bilibili.com resAppend://`
<script src="https://cdn.jsdelivr.net/npm/eruda"></script>
<script>eruda.init();</script>
`
Modify the response content of the mobile page to load the debugging tool Eruda, making it easier to debug on mobile devices.
It is worth mentioning that whistle has a very annoying feature. Whistle itself does not support this inline writing style and requires setting {key} in another panel or using a local file, which is very troublesome.
Therefore, LightProxy adds a layer of escape, saving the inline code as a temporary file. When you open whistle, you can see that the actual configuration sent to whistle is similar to this:
m.bilibili.com resAppend:///var/folders/_l/hbcxcqh522s_vls68417h2m40000gn/T/lightproxy/0-152.txt
Modify response headers
/.*bilivideo\.com\/.*300(\d){2}\.m4s/ resHeaders://`{
'x-service-module': 'test-video'
}`
/.*bilivideo\.com\/.*302(\d){2}\.m4s/ resHeaders://`{
'x-service-module': 'test-audio'
}`
/.*bilivideo\.com\/.*\.flv/ resHeaders://`{
'x-service-module': 'test-flv'
}`
Regular expressions are used here to match different rules for different types of files.
Modify cookies
m.bilibili.com/video/ resCookies://`{
ab: '0000test',
}`
Modifying cookies on mobile devices is not so convenient, so I use this rule, which essentially modifies the Set-Cookie in the response headers.
Host forwarding
172.22.33.166 s1.hdslb.com player.bilibili.com static.hdslb.com
In addition to supporting various matching patterns, it also supports traditional hosts syntax rules. SwitchHosts can be discarded.
Simulate network exceptions
*.bilivideo.com replaceStatus://403 includeFilter://m:get
*.bilivideo.com resSpeed://2000
*.bilivideo.com resDelay://3000
The various functions for simulating network exceptions deeply touch my pain points.
In the example, *.bilivideo.com matches bilibili video CDN addresses.
(1) Simulate CDN status codes to debug timeouts or exceptions in CDN addresses. In the days without LightProxy, I could only mock or wait for a long time for the video address to timeout in the code.
(2) Simulate slow speed to debug stuttering or automatic resolution switching. It can be used as a substitute for Chrome Network Throttling.
(3) Simulate CDN request timeouts to debug CDN streaming timeouts. Without LightProxy, I could only carefully control Chrome Network Throttling. If it is set too small, the request will fail, and if it is set too large, the timeout will not be long enough.
Node.js rules
LightProxy also has a cool feature, which is to write rules using Node.js. Here is an official demo. I haven't found a use case for this feature yet, but it just feels cool.
github.com/alibaba/lightproxy scriptfile://`
exports.handleRequest = async (ctx, next) => {
// do sth
// ctx.fullUrl can get the request URL
// ctx.headers can get the request headers
// ctx.options contains some special request header fields, which can be used to obtain additional information, such as the set rules
// ctx.method gets and sets the request method
// const reqBody = await ctx.getReqBody(); gets the Buffer data of the request body, returns null if there is no data
// const reqText = await ctx.getReqText(); gets the text of the request body, returns '' if there is no data
// const formData = await ctx.getReqForm(); gets the form object, returns an empty object {} if it is not a form
// ctx.req.body = String| Buffer | Stream | null; modifies the request content
// next method can set next({ host, port });
// Only after executing the next method can the normal request be sent out
const { statusCode, headers } = await next();
// do sth
// const resBody = yield ctx.getResBody();
// const resText = yield ctx.getResText();
// ctx.status = 404; modifies the response status code
// ctx.set(headers); batch modifies the response headers
// ctx.set('x-test', 'abc'); modifies the response headers
// ctx.body = String| Buffer | Stream | null; modifies the response content
ctx.body = 'test';
};`
From the above examples, I believe everyone has their own understanding of the usage of LightProxy / whistle.
Finally, there is one more thing worth mentioning. What should I do with the magic internet access after using these debugging proxy tools?
Debugging and magic internet access use different proxies. I am a person who focuses on Google programming, and constantly switching proxies is too troublesome. My approach is to hand over the system proxy to Surge, use Surge for traffic shaping, create a LightProxy proxy, and then edit the Surge rules to only assign the requests that need to be debugged to LightProxy.
The above is my current practice of web debugging proxy.