URL 的 # 片段為什麼不會出現在伺服器日誌裡
瀏覽器發出 HTTP 請求時，# 後面的內容留在本機。閱後即焚把解密金鑰接在 s.html?id={id}#{key} 的 # 之後：伺服器只收到密文編號，看不到金鑰。閱讀頁對接收方公開，不必先註冊。下面把這條邊界拆開，並寫出當場核對的步驟。
# 後面 扮演什麼
秘密出現在位址列，不等於伺服器日誌裡一定有一份副本。這個判斷對查詢參數大體成立，對片段不成立。
維運把臨時密碼塞進聊天軟體、客服把後台地址連同 token 一起轉發時，最怕的往往不是「對方看得到」，而是「中間每一跳都可能留下一份完整連結」。很多人因此預設：只要秘密出現在位址列，伺服器日誌就一定有一份副本。
一段完整地址可以拆成三塊。協定和主機決定瀏覽器連誰；路徑和問號後面的查詢參數決定要哪份資源，這兩塊會出現在 HTTP 請求行裡。井號之後的字元叫 fragment，中文常譯作片段。它最初用來告訴瀏覽器滾到頁面上的某個錨點，後來前端腳本也用 location.hash 在本機讀這段文字。伺服器既收不到它，也不該拿它做路由或鑑權。
把金鑰放在 # 後面，並不是又發明了一種加密演算法。它只是利用瀏覽器長期遵守的傳送邊界：同一條連結可以同時攜帶「給伺服器的編號」和「只給當前分頁的金鑰」。UsePwd 閱後即焚用的就是這個邊界。建立頁和閱讀頁都開啟即用，雙方都不用註冊；伺服器只暫存密文，明文和金鑰預設不作為請求正文發出。
真正發出去的是 哪一段
看 s.html?id=abc123#the-key。瀏覽器發出的 GET，請求行通常只有路徑和 id。#the-key 不在請求裡，也沒有日誌可記。
這是 URL 標準長期如此，不是某一家站點的私有約定，更不是「伺服器答應不看」。表裡的「伺服器能不能看到」指的是：在 TLS 終止之後，源站或你自己控制的反向代理，能不能從這次 HTTP 請求裡讀到該欄位。它不討論本機已被控制、擴充功能能讀頁面，或對方截圖另存的情況。
?id=abc123&key=secret
整段出現在請求行。常見伺服器日誌通常會留下完整 URL。
#secret
瀏覽器不把它當作請求的一部分。常見伺服器日誌沒有這一段可記。
ciphertext
建立閱後即焚時實際上傳的部分。UsePwd 這裡只有密文、有效小時數和閱讀次數。
一個常見誤區是：「已經用了 HTTPS，日誌就看不見。」傳輸加密保護的是線路上的內容不被中間人讀到明文。源站和你自己控制的反向代理，在 TLS 終止之後，仍然能看到完整的請求行。所以 HTTPS 並不能把 ?key= 從伺服器日誌裡抹掉。片段之所以不進日誌，是因為它根本沒被髮出去，不是因為線路被加密了。
另一個容易忽略的通道是 Referer。預設情況下，有些跳轉會把「來源頁的 URL」帶給下一站。現代瀏覽器在 HTTPS 之間跳轉時，預設策略通常會去掉 fragment；查詢參數卻仍可能出現在 Referer 裡。這也是一次性金鑰更適合放在 # 後、而不是 ?key= 的原因之一：你沒法要求每一個下游站點都承諾不記來源地址。
片段不進 HTTP，不等於「連結本身不能被複制」。位址列裡的完整字串，包括 # 後面的金鑰，仍然會出現在本機歷史、分享預覽和你親手發出的訊息裡。本文只解釋伺服器日誌這一層，不把片段寫成萬能保險箱。
開啟網路面板 就能看見
目標不是證明「全世界都看不到」，而是證明：這次發給 UsePwd 的 HTTP 請求裡，沒有 # 後面的金鑰。
-
01
開啟閱後即焚建立頁
進入閱後即焚。頁面開啟即可用，不必登入。輸入一段你認得出來、但不要用真實生產金鑰的示例文字。
-
02
開啟網路面板並清空記錄
按 F12 或右鍵選擇檢查，切到網路（Network）。必要時清空已有請求，避免和頁面首次載入混在一起。
-
03
建立一條連結
提交後，瀏覽器會先在當前分頁用 AES-256-GCM 加密，再向
/api/secrets傳送請求。欄位是ciphertext、ttl_hours、max_reads。產生的分享地址形態是s.html?id={id}#{key}。 -
04
檢查建立請求
點開那條 POST。請求 URL 裡不應出現
#後面的金鑰；請求正文裡應是密文和兩個數字，不是你剛輸入的那段示例文字。 -
05
再開啟閱讀頁核對 GET
用同一條連結開啟閱讀頁。隨後的 GET 或狀態查詢，路徑裡只有
id。把位址列裡#後的字串，和網路面板裡的請求 URL 並排對照：前者在本機，後者沒有這一段。
生產環境可能還有發往 /tj/ 的流量分析。載荷是頁面與按鈕名，例如「建立連結」，不是明文、不是金鑰、也不是檔案內容。本機預覽不會發送分析。若你只關心「金鑰有沒有進 HTTP」，先過濾出 /api/secrets 即可，不必把分析請求誤當成密文通道。
這組步驟和安全說明裡「明文會不會離開瀏覽器」是互補的：安全說明回答本機計算的範圍，本文只把 URL 拆開，說明為什麼日誌裡沒有 # 那一段。兩頁都不代替建立頁上的操作表單。
閱後即焚怎樣 利用 這條邊界
編號走查詢參數，金鑰走片段。伺服器只知道有一份密文、能讀幾次、何時過期，不知道用什麼解開。
建立時，當前分頁用 Web Crypto 產生隨機金鑰，按 AES-256-GCM 加密文字，再把密文交給伺服器。返回的編號寫進 ?id=；金鑰只接在 # 後面。
閱讀頁對接收方公開。對方開啟 s.html?id={id}#{key} 時，瀏覽器先用 id 向伺服器取密文或詢問狀態，再用本機儲存的片段金鑰解密。達到建立時設定的次數後，伺服器刪除密文，連結無法再讀。接收方同樣不用註冊。閱讀頁本身是臨時密文場景，不作為本站的收錄入口；要理解產品能力，應回到建立頁或本篇的核對步驟。
把金鑰放在片段裡，解決的是「伺服器日誌和請求行」這一層。它不解決「你把完整連結發給了誰」。聊天軟體、郵件、工單系統都會儲存你貼上的整串地址。誰拿到完整連結，誰就同時拿到編號和金鑰。閱後即焚限制的是伺服器側的密文壽命和閱讀次數，不是接收方是否截圖、是否轉發。
和查詢參數方案差在哪
有些一次性連結把解密材料寫成 ?k=。實現簡單，但每次開啟都會把金鑰寫進請求行，CDN、WAF 和源站伺服器日誌都能留下一份。片段方案多寫一個井號，換來的是：託管側即使完整記錄 URL，也缺解開密文的那一半。代價是你必須提醒接收方複製完整連結，不要只複製問號前面的部分；缺了 # 之後，閱讀頁只能取到密文，無法在本機解開。
這也是為什麼本文不把閱後即焚寫成「密碼管理器」或「可以找回的保險箱」。UsePwd 沒有帳號，沒有密碼庫，也不能按使用者找回密碼。連結丟了、片段被截斷、次數用盡，伺服器都無法替你還原明文。身分說明見關於。
不要把片段金鑰理解成「只有受信伺服器能解密」。事實正好相反：伺服器沒有這段金鑰，也無法代為解密。能解密的是任何開啟完整連結的瀏覽器分頁。信任邊界在「誰拿到整串地址」，不在「哪一臺伺服器更可靠」。
片段 擋不住 的幾件事
把「不進伺服器日誌」讀成「絕對安全」，會漏掉幾條同樣能核對的邊界。先列出來，避免把一篇原理文當成保證書。
# 之前的 URL，但你發給真人的訊息裡仍有完整金鑰。
適合閱後即焚的，是你信任傳送通道、看完即止的一次性交接：臨時密碼、一次性 API Key、短時驗證碼。不適合當長期保險櫃，也不適合代替面對面交付高價值主金鑰。
檔案備份是另一條路徑。單檔案不超過 5 GB 的本機加解密，走檔案加密盒：AES-256-GCM 在當前分頁完成，輸出 .lock / .enc，檔案預設不上傳。那是「自己留一份密文檔案」，不是「把金鑰塞進 URL」。兩條工具不要混用成同一種保證。
交接時怎麼 選通道
你必須把一段短秘密交給另一個人，又不希望託管側的伺服器日誌留下能解開它的材料。按下面的順序判斷，而不是先問哪家站點口號更響。
若秘密只需要被讀有限次數，並且雙方都能開啟瀏覽器，用閱後即焚：明文在本機加密，編號走 ?id=，金鑰走 #，開啟即用。建立之後用網路面板對照一次，確認 POST 正文是密文、GET 的 URL 沒有片段。若你其實需要長期儲存、多裝置同步或找回，那已經超出本站能力，請使用專門的密碼管理器，不要把 UsePwd 理解成帳號系統。
若秘密根本不該進任何第三方頁面，就不要產生連結：當面口述、離線介質，或只在雙方已有的端到端通道里傳。片段方案減少的是「伺服器日誌裡的金鑰」，不是「世界上所有能看見螢幕的人」。能分清這兩層，才不會把一篇 URL 原理文讀成產品擔保。
密碼本身強不強，是另一件事。產生 6–128 字元隨機密碼用密碼產生器；要在本機看強度並對照隨頁面提供的公開洩露弱密碼名單，用密碼檢測。檢測不是全網撞庫，待測密碼不會上傳。外發連結或工單正文前，用隱私清理去掉追蹤參數或做遮罩。這些頁面和本篇一樣開啟即用，頂欄右側只有語言切換。
讀完去 當場核對
文章回答「為什麼日誌裡沒有 # 後面那一段」。要產生一條可焚毀的加密連結，開啟閱後即焚即可，不必先註冊。