今天有個需求是這樣的, 允許特定 IP 訪問特定的網站, 乍看下會這樣下:

acl AllowedIPs src 192.168.100.0/24
acl AllowedDomains dstdomain .google.com .yahoo.com
http_access allow AllowedIPs
http_access allow AllowedDomains
http_access deny all

但是這樣會變成 OR 的邏輯, 也就是只要白名單 IP, 或是白名單域名(包含子域名), 就會放行, 與原本需要的特定 IP 訪問特定網域不同.

所以若是要 AND 的邏輯, 就必需寫在同一行如下:

acl AllowedIPs src 192.168.100.0/24 
acl AllowedDomains dstdomain .google.com .yahoo.com
http_access allow AllowedIPs AllowedDomains 
http_access deny all

這樣就只有特定 IP 訪問特定網域時才能使用, 否則都會是 403回應囉.

這在設定內網存取外網時特別有用.

官方文件: https://www.squid-cache.org/Doc/

不過若是想快速測試不想改動自己的 Browser設定, 可以用 curl 工具來進行測試, 說明如下:

正常不使用 Proxy的狀況來訪問:

curl https://ip.diary.tw/

可以問到自己的 IP. 若是要觀察 http header, 可以使用 -i, 會同時輸出 header 與察容, 或使用 -I來顯示 header only:

curl -i https://ip.diary.tw/
curl -I https://ip.diary.tw/

若是多加上 proxy server, 則多加上 -x 或是 –proxy 方式指定 proxy server, 後面再加上要查詢的網址:

curl -x http://[username]:[password]@proxy.example.com:80 https://ip.diary.tw/

若 proxy server有要驗證, 可以同時將 [username]:[password]寫上來直接帶入, 若沒有則可以省略, 若只要查詢 header only就組合上面的指令:

curl -x http://[username]:[password]@proxy.example.com:80 -I https://ip.diary.tw/

這樣就可以準確而快速地測試 proxy server是否能正常工作並協助你帶不同的出口 IP.

參考資料:

• https://oxylabs.io/blog/curl-with-proxy
• https://stackoverflow.com/questions/9445489/performing-http-requests-with-curl-using-proxy

若是想要快速而輕量地達成這個 API的保護, 可以透過 Worker 來檢查 x-signature 的 header 來實現.

在 Cloudflare 的 Workers & Pages 介面,  Create application, 然後給定一個名稱如 api-check, 然後在右上角的 Edit Code 進入程式編輯器.

輸入以下程式碼:

const EXPIRY_SECONDS = 300;

export default {
  async fetch(request, env, ctx) {
    // 1. 將您的秘密金鑰設定在環境變數 (安全起見建議後續設定為 Secret)
    const SECRET_KEY = env.API_SECRET_KEY;
    
    const url = new URL(request.url);
    const apiPath = url.pathname;
    const host = url.host;

    // 2. 擷取外部夥伴傳入的 X-Signature 標頭
    const xSignature = request.headers.get("X-Signature");
    if (!xSignature) {
      return new Response(JSON.stringify({ error: "Unauthorized: Missing X-Signature header" }), {
        status: 401,
        headers: { "Content-Type": "application/json" }
      });
    }

    // 3. 解析標頭格式 (預期格式: token-timestamp)
    const parts = xSignature.split("-");
    if (parts.length !== 2) {
      return new Response(JSON.stringify({ error: "Unauthorized: Invalid signature format" }), {
        status: 401,
        headers: { "Content-Type": "application/json" }
      });
    }
    const [clientToken, timestampStr] = parts;
    const clientTimestamp = parseInt(timestampStr, 10);

    // 4. 驗證時間戳記是否超時 (防止重放攻擊)
    const currentTimestamp = Math.floor(Date.now() / 1000);
    if (Math.abs(currentTimestamp - clientTimestamp) > EXPIRY_SECONDS) {
      return new Response(JSON.stringify({ error: "Unauthorized: Signature expired" }), {
        status: 401,
        headers: { "Content-Type": "application/json" }
      });
    }

    // 5. 使用 Web Crypto API 在本端重新計算 HMAC-SHA256
    // 簽章組合公式：路徑 + 網域 + 時間戳記 (符合原 WAF v0 規範)
    const messageStr = `${apiPath}${host}${clientTimestamp}`;
    
    try {
      const encoder = new TextEncoder();
      const keyData = encoder.encode(SECRET_KEY);
      const messageData = encoder.encode(messageStr);

      const cryptoKey = await crypto.subtle.importKey(
        "raw",
        keyData,
        { name: "HMAC", hash: "SHA-256" },
        false,
        ["sign"]
      );

      const signatureBuffer = await crypto.subtle.sign("HMAC", cryptoKey, messageData);
      
      // 將計算結果轉為十六進位字串 (Hex)
      const serverToken = Array.from(new Uint8Array(signatureBuffer))
        .map(b => b.toString(16).padStart(2, '0'))
        .join('');

      // 6. 比對客戶端與伺服器端的 Token 是否一致
      if (clientToken !== serverToken) {
        return new Response(JSON.stringify({ error: "Unauthorized: Signature mismatch" }), {
          status: 401,
          headers: { "Content-Type": "application/json" }
        });
      }
    } catch (err) {
      return new Response(JSON.stringify({ error: "Internal Server Error during verification" }), {
        status: 500,
        headers: { "Content-Type": "application/json" }
      });
    }

    // 7. 驗證通過，將請求原封不動轉發 (Proxy) 給後端的真實源站
    // 註：fetch(request) 會保留原始的 URL、Header 與 Body
    return fetch(request);
  }
};

其中的 EXPIRY_SECONDS 就是限制這個 x-signature 效期只有 300 秒, 你可以依實際的狀況增加或減少這個過期秒數設定, 完成後按下 deploy.

然後我們要將這個程式中用到的 API_SECRET_KEY 放在 Workers & Pages 的 Setting 中的 Variables, 所以按下左上角回到 Workers & Pages 頁面, 切換到 Setting 頁籤, 在最上面的 Variables & Secrets 中, add 一個 Secret 的變數, 內容請自訂, 如 x-123-456-789, 一樣要 deploy 即可, 到這裡完成 Workers 的程式準備.

接下來要透過 Domains 來綁定對應的 API 服務, 若你原本的 API 服務是在 myapi.example.com/api/v1/xxxx 這樣, 你可以在 Workers & Pages 下的 Domains 中, Add Domain, 設定對應的主域名, 然後選擇 Route Pattern, 指定 myapi.example.com/api/* 這樣的路徑, 按下 add route 完成設定, 到這裡就把 server 端在 Cloudflare 上的配置設定完成了.

接下來就是 Client 的部分了, 由於有自定義了 x-signature header, 所以我們就是利用自己的程式來實作這個部分, 把 x-signature header 做出來, 再進行訪問即可, Python 程式如下:

import hmac
import hashlib
import time
import requests
from urllib.parse import urlparse

# 1. 設定基本資料
SECRET_KEY = "x-123-456-789"

api_url = "https://myapi.example.com/api/v1/users"

parsed_url = urlparse(api_url)
api_path = parsed_url.path
host = parsed_url.hostname

# 2. 取得當前 Unix 時間戳記 (秒)
current_time = int(time.time())

# 3. 依照 Cloudflare 規範組合簽章訊息 (路徑 + 時間戳記)
# message = f"{api_path}{current_time}"
message = f"{api_path}{host}{current_time}"

# 4. 使用 HMAC-SHA256 進行雜湊，並轉為十六進位字串
token = hmac.new(
    SECRET_KEY.encode('utf-8'),
    message.encode('utf-8'),
    hashlib.sha256
).hexdigest()

# 5. 將「Token」與「時間戳記」用格式 `token-timestamp` 組合起來
# 這是 Cloudflare is_timed_hmac_valid_v1 函數要求的標準格式
x_signature = f"{token}-{current_time}"

# 6. 帶入 Header 發出請求
headers = {
    "X-Signature": x_signature
}

response = requests.get(api_url, headers=headers)
print(response.json())

其中的 SECRET_KEY 與前面 Cloudflare 中設的 API_SECRET_KEY 設定為一樣的就可以了, 這樣就可以在不傳遞 shared key, 又可以有效地透過這個簡易的 x-signature header 來訪問 API了.

來測速看看吧:

很不錯的測速效果呢, 有架站的朋友可以試試吧!

為了安裝 agy, 先看了一下官方資料, 原來必須先裝 Antigravity (IDE) 後才能安裝 Antigravity CLI (不過現在拿掉了 – https://antigravity.google/download#antigravity-cli), 有兩件事我需要先確認才能將 Gemini CLI 轉到 Antigravity CLI:

1. 是否一定要 Antigravity (IDE)
2. 是否仍可以使用連接 Gemini Pro 方案的帳戶而不只有 API連接方式

為了測試一下這兩個問題, 所以先開了一台 DigitalOcean VM 來安裝 Antigravity CLI:

curl -fsSL https://antigravity.google/cli/install.sh | bash

很快地就裝好了, 然後用 agy 指令啟動, 一樣可以連接 Gemini Pro 帳戶, 連接程序與原本 Gemini CLI 相同, 於是就接著測一下開發的功能, 發現很快很不錯, 而且是用 Gemini Flash 3.5 模型, 比原本在 Gemini  CLI 中的最高 Gemini Pro 3.1 還要新, 而且介面比原本的好, 原來的 Gemini CLI 是用 node js 寫的, Antigravity CLI 則是改用 Go 寫的, 看起來有對介面再優化過了, 所以雖然不得不, 但也算是升級了.

於是就放心在原本的開發環境來安裝, 很快裝好後, 連接 Google 帳戶完成, 繼續來開發原本的專案, 效果很不錯, 而且也更快更強大了, 非常推薦原本在用 Gemini CLI 的朋友們快來升級到 Antigravity CLI.

另外原本在 Gemini CLI 在美國上班的尖峰時間會慢的問題, 在 Antigravity CLI 目前還沒有這個狀況, 再加上可用的模型更多, 非常值得升級.

從無到有打造一個程式, 不用半天的時間, 第一個寫的小程式是python 專案, 利用 speedtest-cli 來進行網路的測速, 並且記錄到 sqlite 資料庫, 再利用 streamlit (這個是 Gemini CLI建議的) 來進行 dashboard 的介面展示, 整個專案很快就完成了, 的確非常快速方便, 畫面如下:

於是就打算再來寫個更複雜一點的程式, 就是一個小型的社群網站, 這次就和 AI 互動比較多, 先討論規畫再實作, 於是用 Nodejs 與 Mysql (後來還加上了 Redis 可以加速快取) 來進行這個社群網站的開發, 做得來有模有樣的, 真的很不錯, 花了一共約 10多個小時 (分好幾天進行), 有個雛形出來了, 目前已有的功能有會員、好友、通知、發文(含相片、編輯、刪除)、留言、按讚、hashtag、後台管理等, 貼文中支援 markdown 語法、Youtube 連結會自動 embed youtube player 、Instagram 相片、reel 連結自動 embed 對應語法等功能, 會再持續增加更多的功能進行, 目前就想成一個都是公開內容的 facebook 吧!

一開始用還蠻順利的, 而且 quota 還蠻大的, 但是最近發現晚上 Gemini 反應速度大幅下降了, 白天還好, 所以可以多利用白天來進行或是就把指令給出讓它自行執行(RUN 在 tmux session 裡才不會登出), 這樣就可以用零散的時間來進行開發了.

有興趣的網友們可以玩看看, 也順便給些建議吧!

網址: https://socialnet.diary.tw/

Claude老是達到用量上限？4個情境、9個技巧，教你有效縮減token

這裡有個好工具, 而且是 Cloudflare 提供的:

https://markdown.new/

將提供給 AI 閱讀的內容進行 markdown 化, 舉例, 將某網頁內容 markdown化, 如下:

https://markdown.new/https://diary.tw/archives/2559

就可以將原來的 web page 內容轉為 markdown 的文檔格式, PDF 也可以哦, 如:

https://jmh.mohw.gov.tw/storage/files/rUxcxnpNHJyTDBRGji1itnZYkQXEZmUIIWpAh2iS.pdf

加上 markdown.new 後:

https://markdown.new/https://jmh.mohw.gov.tw/storage/files/rUxcxnpNHJyTDBRGji1itnZYkQXEZmUIIWpAh2iS.pdf

如此一來, 便能有效地將原本網頁或是 PDF檔式的檔案轉換成對 AI 較有效率的 markdown 格式了.

另外若是需要其他的檔案格式轉換為 markdown, 一樣可以利用這個工具 – file to markdown:

https://markdown.new/file-to-markdown

支援 20多種的檔案格式, 如: PDF, DOCX, XLSX, images, CSV, JSON, TXT, XML 等. (不過若是 TXT 應該是不太需要再轉為 markdown 了, 因為已經很小了)

反之若有需要閱讀 markdown 的內容, 則可以使用這個 markdown viewer 工具:

https://markdownviewer.pages.dev/

[2026/5/5 11:02] 若是檔案不適合用線上工具，可以使用這個地端的轉換工具 Markitdow  https://github.com/microsoft/markitdown

繼續閱讀:

• https://blog.cloudflare.com/markdown-for-agents/
• https://free.com.tw/markdown-new/
• https://keychtouch.pixnet.net/blog/posts/869493618440938202

由於原本一直是 Google One 的 200GB 每月 90元方案, 不過因為去年有台哥大的 Perplexity AI 一年方案, 已使用了一年, 剛好因為換 Google Pixel 10 Pro 手機, 也提供了一年的 Gemini AI Pro 方案, 所以變成了每個月 0元 2TB空間, 才剛用一個月不到, 馬上就被升級到 5TB, 這樣真的很划算耶, 空間大而且又有 Gemini AI Pro, 很划算耶.

剛登入 Google Drive 來看, 已經被升級到 5TB 空間了, 真棒!

繼續閱讀:

• https://applealmond.com/posts/308905
• https://tech.udn.com/tech/story/123454/9419221

Cisco 透過技術方法來分析與檢討目前坊間的LLM大語言模型的資安能力, 希望透過這樣的方式來評估現有的LLM於應用時應該要補強或留意之處.

排行榜在這裡: https://leaderboard.aidefense.cisco.com/rankings

看起來 Anthropic 的 Opus, Sonnet, Haiku 都有不錯的表現, 其他大廠的LLM也都不惶多讓, 透過右上角的 All Models 的切換, 我們可以看到所有被測試的 LLM 表現.

測試的方法在這裡可以看到: https://leaderboard.aidefense.cisco.com/methodology

不過在 Facebook 的本身的網站或 APP 上, 不會受到影響, 會受到影響的是第三方網站上 Embed Facebook Like Button, 將會在 2026/2/10 之後, 變成一個 0x0 的圖像, 這樣的退場機制, 除了很優雅的不影響這個網站的呈現與排版外, 更重要的是, 一個時代的眼淚.

過去的 Web 2.0開始, 大量的網站互動, 使用者生成內容, 藉由社群媒體的力量來推廣與 Social Plugin 的互相串接, 讓在第三方網站上也可以看到這個 Facebook 的按讚功能, 隨著時間的演進, 官方也即將下架了, 之後這個在第三方網站上的按讚功能, 就再也看不到了呢!

另外還有 Comment Plugin 也是一樣會隨之下架, 所以後也都會看不到了呢.