Soptq

Soptq

Probably a full-stack, mainly focusing on Distributed System / Consensus / Privacy-preserving Tech etc. Decentralization is a trend, privacy must be protected.
twitter
github
bilibili

Recording a miraculous ZEIT Debug experience

The thing is, as we all know, because my main blog involves some dynamic content and optimization during each build, it is hosted on ZEIT's server. Specifically, during the build process, I start a local NodeJS server through a script, and Jekyll calls instructions or results through RPC. I randomly set the NodeJS server to port 5001, and this configuration has been running stable for over a year.

Then, starting about a year ago, ZEIT would randomly throw errors during the blog's build process, saying that HTTP requests cannot be sent to the HTTPS server. I was confused because my NodeJS server is an HTTP server, and it's just a temporary server during the build process that gets shut down after deployment. It seems like there's no need for it to use HTTP, right? But those aren't the main points. The main point is that the blog wasn't being built correctly and deployed, so I started investigating the cause. My first thought was that maybe Express forcefully defaults to HTTPS for some reason, although logically it seemed unlikely, but nowadays software can do anything for security reasons. However, after researching, I found that this wasn't the case. Then I started thinking that maybe ZEIT proxies all HTTP connections to HTTPS by default for security reasons, including internal connections.

So, before I was ready to send an email to ZEIT engineers, I decided to create a minimal reproducible project to support my argument in the email. Okay, the weirdest thing happened, I couldn't create such a stable reproducible minimal project. With the same configuration and version, my blog's build process would throw errors, but if I started a new project, there would be no issues. Plus, the errors during my blog's build process weren't consistently triggered. Initially, it had a 10% chance of occurring, but gradually increased to a 90% chance, but never 100%. By this point, I was starting to lose it.

So, I still sent an email to the ZEIT engineers, and they told me it shouldn't be a ZEIT issue, but rather my own problem. I found that believable because if it were a ZEIT issue, many open-source project homepages and even many commercial projects using ZEIT as their provider would have already sent legal letters to ZEIT. So, I started doing a detailed audit of my code. Actually, there isn't much code for starting the NodeJS server, just under 50 lines, but I looked through it over and over again for a long time and still couldn't find any issues. Moreover, according to the error message, the server should have been successfully started, it's just that I don't know why it only accepts HTTPS requests. But on the server side, I clearly started an HTTP server, so why did it end up being an HTTPS server? Plus, the process of starting the server is in the final stage of my blog's build, preceded by about 10 minutes of dependency installation, foreplay, and so on. In other words, every time I debug, even if I only change one character, I have to wait at least 10 minutes to see the results. I was really on the verge of a breakdown.

After countless trial and error attempts (because I had no idea where the problem was), my brain suddenly went blank, and I changed the port number from 5001 to 4001. And then, the build was successful...

In other words, my server never actually started successfully, but ZEIT had a service running on port 5001... And for some reason, my server startup script didn't throw an error for a failed startup due to port occupation.

But the question is, why wasn't the fact that port 5001 was occupied mentioned in the documentation? I guarantee that I couldn't find any information on ZEIT occupying port 5001 anywhere on the internet, and it's even random? Sometimes it's occupied, sometimes it's not?

So, this problem that has been bothering me for almost a year was resolved by simply changing the port...

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.