作者： 白翼

Happy 2026 fam~
Source: https://www.youtube.com/watch?v=bbCwwE_zAUM

It is my sincere advice to everyone to avoid using Azure’s WordPress on App Service, for the following reasons:
(Disclaimer: As the title suggests, this is biased – Azure has never been easy for me to use or understand, and I am not an Azure power user.)

• The WordPress image relies on a Unison process to monitor filesystem events, syncing content between /home/site/wwwroot (the default FTP destination) and /var/www/wordpress (where the site is actually served).
  
  This introduces operational complexity to an already non-transparent build (none of this is documented in https://github.com/Azure/wordpress-linux-appservice). Even worse, filesystem monitoring never worked correctly in our environment.
  
  Update: After suddenly thinking to search for /var/www/wordpress in the GitHub repository, I finally found this document: https://github.com/Azure/wordpress-linux-appservice/blob/main/WordPress/enabling_high_performance_with_local_storage.md, which explains the behavior. However, it states that this feature is not enabled by default, but I don’t believe that was the case with this “Managed WordPress.”
• It does not automatically create a Log Analytics workspace, which makes no sense to me. I’m really not a fan of how logging on Azure works – if you forget to enable a Log Analytics workspace, no logs are retained. When an outage happens, you’re left with nothing to investigate.
• Debugging performance issues on WordPress on App Service was extremely unpleasant, especially given the lack of documentation on how Microsoft’s WordPress image actually works or what the recommended debugging steps are when Metrics provide no useful insight.

For these reasons, I would recommend everyone to just host WordPress on a standalone VM any day, or using an inexpensive managed WordPress provider from a smaller vendor.

Server update: Now runs on Debian 13 (trixie) + added X25519MLKEM768 support.

I have been using Cloudflare WARP+ for a while, mostly to protect myself when using public Wi-Fi. Today I thought I should give products like NordVPN and Surfshark a fresh try to see if they could surpass WARP’s performance.

During my test, I found that mysteriously both VPNs, when using WireGuard, achieved about 50% slower download speed with my ISP. Switching to OpenVPN (UDP) fixed this. However, if buying a modern VPN service only to end up using OVPN, I might as well build the server myself. (Note: NordVPN also had a much higher success rate when connecting with OVPN (UDP) compared to Surfshark, for some reason.)

In comparison to WARP, people should note that WARP was never designed to be a full-featured VPN. I mainly used it to ensure my traffic is securely sent out to the Internet. And WARP really shines in two things:

• One click and it’s connected. No hassle. (However, server connection speed is slower than NordVPN.)
• Really fast speeds when connecting to local websites, though not so much when multiple hops to other countries are involved.

In light of the findings above, I decided to make use of the 30-day money-back guarantee they both offer. With Surfshark, I simply told the bot I wanted a refund, got redirected to a form, filled it in, and voilà — it was done.

Now, that was a totally different story with NordVPN, despite their similar refund form. With NordVPN:

• First, I had to provide proof via speedtest.net showing slower performance when using NordVPN.
• Then I was asked to change protocols — which is when I discovered OVPN (UDP) actually runs faster. But again, I bought NordVPN specifically for the NordLynx protocol.
• Finally, the live chat (Zendesk Sunshine) was a pain to use. I was asked to upload screenshots, but sending images kept failing. In the end, I managed to upload them as files.

In summary, compared to the straightforward refund from Surfshark, NordVPN really runs through their whole playbook to stop you from getting one. However, NordVPN does at least show a clear “refund request is processing” notice on their billing page, while Surfshark does not (though Surfshark will send you a confirmation email within 24 hours, according to their bot).

Great starting point to actually get to know about Linux. And it is a 6-part course (each <1hr) which is not a heavy task at all.

https://www.youtube.com/watch?v=5osOHhBWKOQ&list=PLSIUOFhnxEiC3YTdxwqZqgEY5imVL8U8J&index=1

1. First, open DevTools on the webpage where you want to capture the popup.
2. Click on Settings.

3. Enable “Global → Auto-open DevTools for popups” and “Console → Preserve log upon navigation”.

10 years later, still mind-blowing.
https://superuser.com/a/727531
ncdu – disk usage analyzer with a text-mode user interface.

今天意外發現自己 1GB 內存的 Rocky Linux 9.2 機子三台全部 OOM 並需要強制重啟…經過監控之後發現 dnf-makecache 在主機死亡前出現在了 htop，馬上鎖定原因並禁用。準備 ASAP 更換成 Debian。

Dnf-makecache.timer is a major liability
https://forums.rockylinux.org/t/dnf-makecache-timer-is-a-major-liability/15371

~# dig @119.29.29.29 www.dnssec-failed.org. A

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @119.29.29.29 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10361
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 400176fcef655802 (echoed)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

;; ANSWER SECTION:
www.dnssec-failed.org.  3600    IN      A       68.87.109.242
www.dnssec-failed.org.  3600    IN      A       69.252.193.191

~# dig @8.8.8.8 www.dnssec-failed.org. A

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> @8.8.8.8 www.dnssec-failed.org. A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16567
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 9 (DNSKEY Missing): (No DNSKEY matches DS RRs of dnssec-failed.org)
;; QUESTION SECTION:
;www.dnssec-failed.org.         IN      A

説明：如果 www.dnssec-failed.org 能夠返回 A 記錄，則代表遞歸 DNS 沒有對 DNSSEC 簽名進行檢驗。
其他還測試了 114.114.114.114，以及 223.5.5.5，均不支持 DNSSEC 校驗。雖然 DNSPod 支持了 DNSSEC 功能，但在國内依然是沒有什麽用處。