電感中的飽和電流 Isat 是什麼?

既然已經了解了額定電流 I_{rms}(受發熱限制),那接下來這個飽和電流 I_{sat}(Saturation Current) 就是電感的另一個關鍵生死線。

如果說 I_{rms} 考驗的是電感的耐熱極限,那麼 I_{sat} 考驗的就是電感的磁吸極限。

1. 什麼是「飽和電流」?

簡單來說:當通過電感的電流大到一個程度時,電感裡面的磁芯(鐵心)再也容納不下更多的磁力線了,這時候的電流值就叫做飽和電流。

規格書上的定義通常更具體:當電感量(L)因為電流增大而下降了 20% 或 30% 時的電流值。

我們可以拿**「海綿吸水」**來做比喻:

  • 正常狀態:乾海綿剛開始吸水時,你倒多少水,它就吸多少(電流增加,磁場成比例增加,電感量維持正常)。
  • 飽和狀態:當海綿吸飽了水,你再繼續倒水,水就會直接流出來,海綿再也無法多吸一滴水(電流再增加,磁場也不會再增加,電感失去儲能能力)。

2. 當電流超過 Isat 飽和了,會發生什麼事?

這也是電路設計中最危險的地方。一旦實際電流超過了 I_{sat},電感會瞬間發生物理特性的崩塌:

  1. 電感量驟降,變成一根導線: 電感之所以能限制電流的變化率,全靠磁芯的儲能。一旦磁芯飽和,電感量(L)會瞬間暴跌(可能只剩下原本的幾十分之一)。這時候,這個電感在電路中就只剩下一根「有微小電阻的銅線」。
  2. 電流瞬間暴增(Spike): 在開關電源(如 Buck 電路)中,如果電感飽和,原本應該平緩上升的電流波形會突然像坐雲霄飛車一樣直線飆升。
  3. 燒毀週邊元件: 這個瞬間暴增的巨大電流,通常會遠遠超過後端晶片、MOSFET(開關管)或二極體的承受極限,進而導致整個電源電路瞬間燒毀。

3. 一張圖看懂:Irms 與 Isat 的本質區別

為了讓你在做紀錄時更清晰,我們可以這樣歸納兩者的差別:

額定電流 I_{rms} (Heating Current)

  • 物理限制:熱效應(銅線發熱)。
  • 對應指標:元件溫度上升(通常以升溫 40°C 為限)。
  • 電流類型:通常看持續的平均電流 / 有效值。
  • 超過的後果:慢慢變熱、絕緣熔化、長期壽命縮短。

飽和電流 I_{sat} (Saturation Current)

  • 物理限制:磁效應(磁芯飽和)。
  • 對應指標:電感值下降(通常以下降 20%~30% 為限)。
  • 電流類型:通常看瞬間的峰值電流(Peak Current)。
  • 超過的後果:瞬間失效、電流暴增、晶片當場燒毀。

實戰挑選心法: 在設計或挑選電感時,電路中的最大持續工作電流必須小於 I_{rms};而電路在開關切換瞬間可能達到的最大峰值電流,必須小於 I_{sat}。這兩個及格線都要守住,電路才會穩定。

規格書中的 DCR 是什麼?

在電子元件(尤其是電感和變壓器)的規格書中,DCR 是一個非常關鍵的直流參數。

什麼是 DCR?

DCR 的全稱是 DC Resistance,中文叫做 直流電阻。

簡單來說,它指的是當元件通過直流電(DC)時,元件自身導線所呈現的電阻值。

  • 物理本質:電感通常是由銅線繞製而成的。雖然我們希望電感在理想狀態下只有「電感量」而沒有「電阻」,但現實中導線本身一定有長度和截面積,因此必然存在微小的電阻。這個繞線整體的電阻值就是 DCR。
  • 測量單位:通常非常小,規格書上多以 毫歐姆(mΩ) 或 歐姆(Ω) 為單位。

DCR 與 額定 Irms 有什麼關係?

這兩個參數在物理上是**直接綁定(因果關係)**的:

  1. DCR 決定了發熱量: 當電流(Irms)通過電感時,DCR 會導致能量消耗並轉化為熱能。這個損耗稱為導線損耗(Copper Loss),計算公式為:P = Irms² × DCR
  2. DCR 越小,額定 Irms 越高:
    • 如果一個電感的 DCR 很大,通過電流時就會劇烈發熱,元件溫度很容易飆升,因此它的額定 Irms(安全電流上限)就會迫變低。
    • 反之,DCR 越小,代表導線材質或架構越好(例如用了更粗的銅線),發熱量低,元件就能承受更大的額定 Irms。

在電路設計中,為什麼 DCR 很重要?

  1. 影響電源轉換效率: 在開關電源(如 Buck、Boost 電路)中,電感的 DCR 會直接吃掉一部分功率。DCR 越低,電源的轉換效率就越高,設備(如手機、筆電)就越省電、越不發熱。
  2. 影響電壓降(Voltage Drop): 當大電流通過電感時,DCR 會產生電壓降(V = I × DCR)。如果 DCR 太大,會導致後端電路收到的電壓被拉低,影響電路穩定性。

總結來說: DCR(直流電阻)是元件與生俱來的寄生缺點。在挑選元件時,通常在相同電感量下,DCR 越小越好,因為它意味著更低的發熱量與更高的電流承受能力(Irms)。

電感中的額定電流 Irms 是什麼?

額定電流,決定了電感是否會熱爆

在電子和電機工程中,I_{rms} 代表均方根電流(Root Mean Square Current)。當它被標示為「額定電流 I_{rms}」時,指的是:

該元件或設備在正常工作環境下,長期連續安全運行的最大交流電流有效值。

為了更容易理解,我們可以把它拆解為兩個核心概念:

1. 什麼是 Rms(均方根 / 有效值)?

交流電(AC)的電流大小和方向是隨時間不斷變化的(例如正弦波)。因為它一直在變,很難用一個單一數值來代表它的做功能力。

因此,科學家引入了 Rms(有效值) 的概念:

  • 定義:讓交流電和某個直流電(DC)通過相同的電阻,如果在相同的時間內產生的熱量(功耗)完全相等,那麼這個直流電的電流數值,就是該交流電的 Rms 值。
  • 數學關係:對於標準的正弦波交流電,它的峰值電流(I_peak)與有效值(I_rms)的關係為:I_rms = I_peak / √2 ≈ 0.707 × I_peak

2. 什麼是「額定」?

「額定」(Rated)是製造商給出的安全邊界線。

當一個元件(如電感、變壓器、電線或保險絲)標示了額定 I_{rms},代表:

  • 熱平衡限制:電流通過元件時會因為內阻而發熱(功耗 P = I_rms² × R)。額定 I_{rms} 是在考慮了元件散熱能力後,允許長期通過的最大電流。
  • 超過的後果:如果實際工作的 I_{rms} 超過這個額定值,元件的溫度會持續上升,可能導致絕緣層熔化、燒毀或壽命急劇縮短。

關鍵區分:額定 I_{rms} vs 額定 I_{sat}(飽和電流)

在挑選電子元件(特別是電感)時,通常會同時看到這兩個參數,它們代表完全不同的物理限制:

額定 I_{rms}

  • 定義:導線發熱所限制的電流有效值。
  • 限制核心:熱效應(溫度上升,通常以令元件升溫 40°C 為標準)。
  • 超過後果:元件過熱、燒毀。

額定 I_{sat}

  • 定義:磁芯飽和所限制的峰值電流值。
  • 限制核心:磁效應(磁芯飽和,導致電感量驟降)。
  • 超過後果:電感失去作用,電路電壓或電流失控。

總結來說: 額定 I_{rms} 就是該元件的交流電流發熱安全線。只要實際電路中的交流電流有效值控制在額定 I_{rms} 以內,元件就能穩定、低風險地持續運作。

🔄 完整重置 Fail2ban(快速清空封鎖與規則)

當出現大量誤封、測試結束、或規則混亂時,
可以將 Fail2ban 重置回乾淨狀態。

以下是最直接的完整重置方法。


⚠️ 注意

此操作會:

  • 清空所有被封鎖 IP
  • 刪除封鎖歷史資料
  • 清空所有 f2b-* 防火牆規則
  • 重新建立 jail 規則

請確保你仍有伺服器存取權限。


✅ 重置步驟

1️⃣ 停止 Fail2ban

systemctl stop fail2ban

2️⃣ 刪除封鎖資料庫(關鍵)

rm -f /var/lib/fail2ban/fail2ban.sqlite3

這一步會清除所有封鎖歷史與 recidive 記錄。


3️⃣ 清空防火牆規則

iptables -F
iptables -X

清除所有自訂 chain(包括 f2b-*)。


4️⃣ 重新啟動 Fail2ban

systemctl start fail2ban

系統會:

  • 自動建立新的資料庫
  • 重新載入 jail
  • 重建 f2b-* chain

✅ 可選:清空 fail2ban log(僅為閱讀乾淨)

truncate -s 0 /var/log/fail2ban.log

注意:
這不影響封鎖狀態,只是清空顯示紀錄。


✅ 完整指令總結

systemctl stop fail2ban
rm -f /var/lib/fail2ban/fail2ban.sqlite3
iptables -F
iptables -X
systemctl start fail2ban

✅ 結語

當規則混亂或測試過程造成大量封鎖時,
回到乾淨狀態,往往比逐條排錯更有效率。

清楚、可控、可驗證,
才是穩定運行的基礎。

🔐 如何檢查及解除 Fail2ban 封鎖的 IP(實戰步驟)

在管理伺服器時,偶爾會遇到某個 IP 被 Fail2ban 封鎖的情況。
這篇文章介紹如何:

  • ✅ 查出是否被封
  • ✅ 找出是哪個 jail 封鎖
  • ✅ 正確解除封鎖
  • ✅ 驗證是否完全清除

以下示例 IP 使用:

X.X.X.X

請替換為實際需要查詢的 IP。


✅ 第一步:查看 Fail2ban log

先從日誌確認是否曾被封鎖:

grep X.X.X.X /var/log/fail2ban.log

如果看到類似:

[sshd] Ban X.X.X.X

代表該 IP 曾被某個 jail 封鎖。


✅ 第二步:確認目前是否仍被封鎖

使用 fail2ban 內建查詢指令:

fail2ban-client banned X.X.X.X

如果該 IP 仍在封鎖名單中,會顯示對應 jail 名稱。

如果沒有任何輸出,代表目前沒有被 Fail2ban 封鎖。


✅ 第三步:解除封鎖(Unban)

若確認需要解除封鎖:

fail2ban-client unban X.X.X.X

這條指令會:

  • 從所有 jail 中移除該 IP
  • 同時更新防火牆規則

✅ 第四步:確認 firewall 是否已清除

Fail2ban 會透過 iptables 或 nftables 進行封鎖。

如果系統使用 iptables,可檢查:

iptables -L -n | grep X.X.X.X

若沒有任何輸出,表示防火牆規則已移除。


✅ 建議完整排查流程

grep X.X.X.X /var/log/fail2ban.log
fail2ban-client banned X.X.X.X
fail2ban-client unban X.X.X.X
fail2ban-client banned X.X.X.X
iptables -L -n | grep X.X.X.X

✅ 補充說明

  • Fail2ban 只負責管理封鎖名單
  • 真正丟棄封包的是防火牆規則
  • 若 unban 後仍無法連線,應檢查是否有其他防火牆或 CDN 層封鎖

✅ 結語

正確的排查順序應為:

  1. 查 log
  2. 查 jail 狀態
  3. 執行 unban
  4. 驗證防火牆

避免直接重啟服務或修改設定,
精準排錯才是穩定運行的關鍵。

WordPress 檔案權限標準設定整理

以下是 WordPress 建議的標準檔案權限設定方式,適合大多數主機環境使用。


一、整個網站權限

# 設定資料夾
find /你的wordpress路徑/ -type d -exec chmod 755 {} \;

# 設定檔案
find /你的wordpress路徑/ -type f -exec chmod 644 {} \;

二、uploads 資料夾

find wp-content/uploads -type d -exec chmod 755 {} \;
find wp-content/uploads -type f -exec chmod 644 {} \;

三、wp-config.php

chmod 600 wp-config.php

或:

chmod 640 wp-config.php

四、檔案擁有者

確認網站檔案擁有者正確,例如:

chown -R www-data:www-data /你的wordpress路徑/

(依主機環境調整使用者名稱)


五、建議安全設定

在 wp-content/uploads 新增 .htaccess:

<Files *.php>
deny from all
</Files>

以上為 WordPress 常見且建議的標準權限設定方式。

使用 Cloudflare WAF 保護 WordPress:阻止 wp-login 攻擊與封鎖 XMLRPC(完整教學)

當你的 WordPress 網站開啟 Cloudflare 橙色雲(Proxy)後,其實 HTTP 攻擊應該在 Cloudflare Edge 層解決,而不是在伺服器層解決。

很多人仍然使用 Fail2ban 嘗試封鎖 wp-login 攻擊,但在橙雲模式下:

  • 真正連線來源是 Cloudflare IP
  • iptables 無法阻擋真實攻擊者
  • 即使封鎖 IP 仍然會有流量進來

✅ 正確做法是使用 Cloudflare WAF Custom Rules。

本教學會示範兩條最重要的規則:

  1. 保護 wp-login.php
  2. 封鎖 xmlrpc.php

✅ 第一條規則:保護 wp-login.php

為什麼需要?

WordPress 的登入頁面:

/wp-login.php

是全球機器人暴力破解的主要目標。

即使你沒有公開登入頁,掃描機器仍然會嘗試。


🔧 建立規則步驟

Step 1:進入 Cloudflare

  1. 登入 Cloudflare
  2. 選擇你的網站
  3. 點擊:
Security → WAF → Custom Rules
  1. 點擊:
Create rule

Step 2:設定 Rule Name

請填寫:

WP-Login Protection

Step 3:點擊「Edit expression」

不要使用上方 Select 下拉選單。

請點擊右側:

Edit expression

Step 4:貼上以下 Expression

(http.request.uri.path contains "/wp-login.php")

如果你希望自己的固定 IP 不被影響,可以使用:

(http.request.uri.path contains "/wp-login.php")
and not ip.src in {你的IP地址}

例如:

(http.request.uri.path contains "/wp-login.php")
and not ip.src in {1.2.3.4}

Step 5:選擇 Action

在「Then take action」中選擇:

✅ Managed Challenge

不要使用 Block,除非你 100% 不需要外部登入。


Step 6:點擊 Deploy

完成 ✅


✅ 效果說明

設定後:

  • 大部分 bot 會被 Challenge 阻擋
  • 真人用戶幾乎無感
  • 攻擊流量不再直接打到伺服器
  • CPU 使用率會下降

✅ 第二條規則:封鎖 XMLRPC


為什麼需要?

WordPress 的:

/xmlrpc.php

經常被利用作:

  • 暴力破解
  • Pingback 攻擊
  • DDoS 放大攻擊

如果你沒有使用:

  • Jetpack
  • WordPress App
  • 遠端發佈功能

✅ 建議直接封鎖。


🔧 建立規則步驟

Step 1:Create rule

同樣進入:

Security → WAF → Custom Rules

點擊:

Create rule

Step 2:Rule Name

填寫:

Block XMLRPC

Step 3:Edit expression

貼上:

(http.request.uri.path contains "/xmlrpc.php")

Step 4:Action

選擇:

✅ Block


Step 5:Deploy

完成 ✅


✅ 建議規則順序

在 Custom Rules 頁面,請確保順序如下:

  1. Block XMLRPC
  2. WP-Login Protection

Cloudflare 會由上而下執行規則。


✅ 設定完成後的架構

啟用後流量流程變成:

攻擊者 → Cloudflare WAF → 被挑戰/封鎖 → 無法到達伺服器

而不是:

攻擊者 → 伺服器 → Fail2ban 分析 → 再封鎖

✅ 安全性更高
✅ 伺服器負載更低
✅ 不再需要 Fail2ban API 同步


✅ 常見問題

Q1:會不會影響 Google?

不會。

Cloudflare 會識別合法 bot,Managed Challenge 不會影響正常搜尋引擎。


Q2:是否還需要 Fail2ban?

建議:

  • 保留 Fail2ban 用於 SSH
  • 保護未使用 Cloudflare 的網站
  • 保護 API 服務

但對 HTTP WordPress 攻擊,可以完全交給 Cloudflare。


✅ 總結

只需兩條規則,你就可以:

  • 阻止 90% WordPress 掃描攻擊
  • 減少伺服器負載
  • 不再依賴 API 封鎖
  • 架構更清晰

Cloudflare WAF 應該成為橙雲網站的第一層防線,而不是伺服器。

WordPress 手動安裝教學(Linux 主機)

以下示範如何在 Linux 主機上手動下載並安裝 WordPress。

✅ 前置需求

  • 已安裝 Apache / Nginx
  • 已安裝 PHP
  • 已安裝 MySQL 或 MariaDB
  • 已建立資料庫與資料庫帳號

📥 步驟一:下載 WordPress

cd /tmp
wget https://wordpress.org/latest.tar.gz

說明:
進入 /tmp 目錄並下載最新版 WordPress 壓縮檔。


📦 步驟二:解壓縮檔案

tar -vxf latest.tar.gz

解壓縮後會產生 wordpress 目錄。


📂 步驟三:複製檔案到網站目錄

rsync -av wordpress/ /var/www/html/

說明:
將 WordPress 檔案同步到網站根目錄(此處以 /var/www/html/ 為例)。

⚠️ 如果你的網站目錄不同,請修改為實際目錄路徑。


🔐 步驟四:修改檔案權限

chown -R apache:apache /var/www/html/

說明:
將檔案擁有者改為 Apache 使用者(CentOS / RHEL 常用 apache)。

🔎 如果是 Ubuntu / Debian 系統:

chown -R www-data:www-data /var/www/html/

🗄️ 步驟五:建立資料庫

登入 MySQL:

mysql -u root -p

建立資料庫與使用者:

CREATE DATABASE wordpress;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;
EXIT;

🌐 步驟六:完成網頁安裝

  1. 開啟瀏覽器
  2. 前往你的網域或 IP,例如: http://your-server-ip/
  3. 依照畫面輸入資料庫資訊
  4. 完成安裝 🎉

✅ 安裝完成

成功後即可登入後台:

http://your-domain/wp-admin

[Fix] PHP Server Monitor Shows “Online” for Failed Pings on Newer Linux Distros

I recently deployed PHP Server Monitor v3.5.2 on my server to keep track of my hosting status. However, right after setting it up, I noticed a very bizarre issue:

I purposely added a completely unreachable, invalid IP to test the Ping monitoring, but the system reported it as “Online” with a latency of 0ms!

I checked the system error logs, but they were completely clean—no error messages at all. A monitoring system that fails to alert you when a server goes down is virtually useless. To fix this fatal flaw, I began a deep dive to troubleshoot the issue.

🕵️‍♂️ The Diagnosis: Where did it go wrong?

Initially, I suspected the server’s PHP security settings (like disable_functions in php.ini) might be restricting the execution of system commands. If the exec() function is disabled, PHP wouldn’t be able to run the system’s ping command.

To test this theory, I wrote a simple PHP diagnostic script (test_ping.php) to check the underlying connection:

<?php
$test_ip = "192.168.255.255"; 
$cmd = "ping -c 1 -w 2 " . escapeshellarg($test_ip) . " 2>&1";
exec($cmd, $output, $return_var);

echo "Return Code: " . $return_var . "<br>";
print_r($output);
?>

The execution results were eye-opening:

  • Return Code: 1 (which means failure)
  • Actual Terminal Output: It clearly printed 2 packets transmitted, 0 received, 100% packet loss, time 1016ms.

This proved that the server environment and permissions were perfectly fine! The system successfully sent the packets and accurately recognized that the IP was unreachable (100% packet loss). The environment was not the culprit.

💡 The Root Cause: Outdated Regex vs. Modern Linux

With the environment ruled out, the root of the problem pointed directly to a bug within PHP Server Monitor v3.5.2 itself.

After digging into the official GitHub repository, I realized the software hasn’t seen a major active update since around 2021. The old codebase uses a very rigid method to determine ping status: it uses Regular Expressions (Regex) to parse the text output of the terminal. If it spots the keyword time anywhere in the output string, it blindly assumes “there’s a response time, so the host must be Online.”

In older Linux distributions, a failed ping (100% packet loss) usually wouldn’t print the time taken at the end of the output. However! In newer Linux distributions (like recent Debian versions), the ping command reliably prints out time 1016ms at the very end, even if every single packet is dropped.

Because of this simple phrase—time 1016ms—the outdated code in PHP Server Monitor gets completely confused. It ignores the glaring 100% packet loss right next to it and falsely reports the server as Online. This is also exactly why the “fix” available in the official development branch still fails on newer Linux systems.

🛠️ The Ultimate Solution: Rewriting the Core Logic

Since official maintenance has stalled, the most reliable way forward is to rewrite the validation logic ourselves. Instead of relying on the app to parse terminal text—which can constantly change depending on the Linux distribution—we should just grab the most honest metric the OS provides: the Return Code (0 means success, anything else means failure).

How to apply the fix:

  1. Access your PHP Server Monitor web directory via SSH or FTP.
  2. Locate and open this specific file: src/psm/Util/Server/Updater/StatusUpdater.php
  3. Search for the protected function updatePing function inside the file (it should be roughly past the middle).
  4. Replace the entire updatePing function block with this updated, precise version:
    protected function updatePing($max_runs, $run = 1) {
        $starttime = microtime(true);
        $ip = $this->server['ip'];
        $os_is_windows = strtoupper(substr(PHP_OS, 0, 3)) === 'WIN';
        
        if ($os_is_windows) {
            // Windows Ping: -n 1 (1 packet), -w 2000 (2000ms timeout)
            exec('ping -n 1 -w 2000 ' . escapeshellarg($ip), $output, $result);
            $output_str = implode("", $output);
            // Windows ping notoriously returns 0 on unreachable hosts. Verify with "TTL="
            $status = ($result === 0 && stripos($output_str, 'TTL=') !== false) ? true : false;
        } else {
            // Linux/Unix Ping: -c 1 (1 packet), -w 2 (2s timeout), capture stderr
            exec('ping -c 1 -w 2 ' . escapeshellarg($ip) . ' 2>&1', $output, $result);
            // Core fix for Linux: Only trust the Return Code! (0 is success)
            $status = ($result === 0) ? true : false;
        }
        
        // Record the response time
        $this->rtime = (microtime(true) - $starttime);

        // If it fails and we haven't reached max retries, try again
        if(!$status && $run < $max_runs) {
            return $this->updatePing($max_runs, $run + 1);
        }
        
        return $status;
    }

Save the file and head back to your PHP Server Monitor dashboard. Test that invalid IP again, and the system will finally behave as it should, properly displaying a red “Offline” status!

📝 Conclusion

Sometimes, when running older open-source software on modern operating systems, official patches might not be enough to resolve bugs caused by OS-level changes. In situations like this, writing a simple script to test the underlying commands directly can help cut through the confusion and point you toward the most effective fix.

If you are using PHP Server Monitor and experiencing this “Fake Online” bug, give this fix a try!

Tags: PHP Server Monitor, Bug Fix, Server Monitoring, Ping, Linux