It has been seven months since I last wrote a progress update. That earlier post documented my move from WordPress to Astro + Fuwari. The blog has now been running steadily for more than half a year, and much of that time has gone into refining it, solving problems I had postponed, and dealing with a few issues I never expected.
Reworking Fuwari from the ground up
I chose Astro + Fuwari after being inspired by Erchashu. Rather than adopting one of the many community forks, though, I cloned the official Fuwari repository again and rebuilt the parts I needed around its original architecture.
The reason was simple: understanding. Using someone else's fully customized version is faster, but it makes it difficult to know why every change exists or whether a feature is actually useful to you. Even excellent code can contain redundant behavior or logic that conflicts with your own needs. Starting from scratch takes more time at the beginning, but it means that later maintenance, new features, and bug fixes are much easier to handle.
Over the past seven months, I gradually added or redesigned the following:
- A short-posts page
- A friends-links page
- A sponsorship page
- An About page
- An Umami analytics card
- An Uptime Kuma status card
- A newly designed footer
- Sponsorship cards
I also adapted the site for server-side rendering on EdgeOne Pages, refined the animations, and made a number of UI adjustments. While working through these changes, I took inspiration from several strong Astro themes, including Mizuki and Firefly.
That work also led to several tutorials, such as guides for adding Giscus comments to Fuwari, enabling Netlify Image CDN, and displaying an analytics card. The analytics-card guide has been the most popular. It puts Umami traffic data in the sidebar. It is not as granular as showing PV and UV figures for every individual post, but it already provides everything I need.
When the old image host disappeared
While continuing to modify Fuwari, an issue I had left unresolved since the WordPress era finally caught up with me.
Back when the site ran on WordPress with InfinityFree hosting, I registered a subdomain under rf.gd. After switching to a static site on Netlify, many images in older posts still pointed to that old WordPress address. I did not think much of it at first. Then InfinityFree deleted the inactive old site, and image resources throughout the blog started returning 404 errors.
I had always intended to build my own image hosting setup after the migration, but moving the files and replacing all the links felt too tedious, so I kept putting it off. Worse still, I had no backup of the old images. They were gone.
The situation was saved, at least in part, by BlogsClub, which I joined last October. Its archive feature periodically captures screenshots of members' homepages and articles. Going through those records, I was able to recover most of the missing images from screenshots. The quality is not ideal, but the content of those posts was preserved. The archive turned out to be far more valuable than I could have expected.
Recovering the images created another question: where should they live from now on?
- A self-hosted Lsky Pro image host would bring server costs and the risk of traffic abuse; if I could no longer afford to renew it, everything could disappear again.
- Free third-party image hosts may eventually shut down or remove files.
- Storing all images in the blog repository would make the repository unnecessarily large and difficult to manage.
In the end, I placed all images in a dedicated repository and deployed that image repository through EdgeOne Pages. The project was originally built purely for this blog, then grew to include a waterfall-style gallery and random-image support. It was later released on GitHub as EdgeOne-Random-Picture, where it currently has 5 stars and 9 forks.
All blog images now use the https://image.tianhw.top/ domain, including my avatar at https://image.tianhw.top/avatar.webp. If EdgeOne Pages ever becomes unavailable, I can move the same repository to Vercel, Cloudflare Pages, ESA, or another platform and simply update the domain's DNS records. Existing image links in older posts would not need to change. The setup costs almost nothing and has been reliably stable.
A new domain and ICP registration
As the site became more complete, I decided to retire the old thw.lol domain and formally switch to tianhw.top, originally registered through NameSilo.
I also wanted to use mainland Chinese cloud services such as Alibaba Cloud ESA and lightweight application servers. In practice, nearly all of them require an ICP filing, and trying to work around that limitation was becoming unnecessarily exhausting.
I therefore transferred the domain to Alibaba Cloud and submitted the ICP application there on January 3, 2026. Eleven days later, it was approved as 鲁ICP备2026002442号-1. During the winter break, I completed the public-security network filing as well; it was approved on February 26, 2026, with the number 鲁公网安备37030302001162号. Both records are now displayed in the footer card.
The process was tedious, but it made the move to the mainland China version of EdgeOne Pages worthwhile. Load times and the overall browsing experience improved noticeably, and using domestic services in the future should be much more straightforward.
Traffic abuse against a static site
A static site may not have much of an attack surface in the traditional sense, but unwanted traffic is still a serious nuisance.
The first incident involved a site I had deployed on Cloudflare Pages. IP addresses from the United States sent enough traffic to generate 196 GB of transfer, despite the entire static site being only a few megabytes. For Cloudflare, that amount was insignificant; I would not have noticed it at all if I had not opened the dashboard and checked the traffic data myself.
The second case was connected to an IPFS image-hosting solution I had shared in a post about building a free image host with IPFS. The setup used EdgeOne as a reverse proxy, and I also made a free image-hosting site that was adopted by several other blogs. That popularity eventually exposed me to collateral damage.
The EdgeOne logs suggested that my own site was not the intended target. Instead, one blog using my image host was under attack. A single image only a few hundred kilobytes in size caused traffic to jump by more than 100 GB, and all of the requests came from domestic IP addresses. Based on similar experiences reported by Erchashu, even a service advertised as offering unlimited traffic may suspend a project if the abuse becomes excessive. I tried to contact the owner of the affected blog without success, so I ultimately blocked the targeted image resource. The ipfs.crossbell.io endpoint effectively became unusable as a result.
The most recent incident targeted my current blog image host, particularly every image on the page for “Bilibili Enhancement Extension — BewlyCat.” This time I retained more complete data. The attacking IP addresses were:
- 43.133.58.242
- 43.134.183.214
- 150.109.25.183
- 43.156.240.167
- 43.156.6.122
- 119.28.101.45
- 150.109.12.53
- 119.28.101.51
- 129.226.197.201
- 129.226.197.194
A lookup through the ThreatBook X intelligence community identified all of them as malicious Tencent Cloud bot hosts. Their records included Webshell scanning, Nmap port scanning, brute-force attempts against Tomcat, WebSphere, and OA systems, as well as SSRF probing.
What may be behind it
These cases may well be related to PCDN traffic laundering. A PCDN participant is expected to contribute CDN offloading capacity to a platform, so an unusually imbalanced upload-to-download ratio can attract an ISP's attention. Artificial download traffic may be used to balance that ratio and avoid restrictions.
Static sites make convenient targets in this scenario. Dynamic sites often fail quickly under attack because many run on modest servers, perhaps with only 2 CPU cores and 2 GB of memory, and have little spare capacity. Static sites can absorb more traffic, while low-speed requests may not trigger protection rules. In that sense, their resilience can make them easier targets for this kind of abuse.
That explanation may fit the domestic traffic, but I still have no clear answer for why overseas IP addresses would be used for the same purpose.
A quick look at traffic
Bing accounts for 85% of traffic sources, followed by Alibaba Cloud Developer Community and GitHub. Chrome represents 50% of browsers, while Chromium-based Edge accounts for 37%.
Thanks to everyone who has visited and supported the site.