網(wǎng)絡(luò)安全應(yīng)用安全后端【免費下載鏈接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.項目地址https://gitcode.com/gh_mirrors/cap13/cap點擊查看免費下載本指南以 Cap Standalone 的 配置選項文檔 為核心系統(tǒng)講解自托管部署該開源 CAPTCHA 服務(wù)時需要掌握的全部配置項從 CORS 跨域策略、靜態(tài)資源Asset server托管到基于 IP 的請求限流、Redis/Valkey 存儲、健康檢查與優(yōu)雅關(guān)閉再到 HashWX / SHA-256 / RSW 三種證明工作量PoW協(xié)議與 instrumentation 挑戰(zhàn)的逐鍵配置最后涵蓋 IP 地理數(shù)據(jù)庫的接入與 Docker 卷權(quán)限問題。讀完本文你將能夠為生產(chǎn)環(huán)境正確設(shè)置環(huán)境變量、鎖定組件版本、排查資源緩存與限流故障并為每個 site key 制定合適的挑戰(zhàn)協(xié)議與難度。本文所有結(jié)論均以本倉庫 standalone/ 目錄下的實際源碼與 官方文檔 為依據(jù)文中給出的默認(rèn)值、取值范圍與環(huán)境變量名均與當(dāng)前倉庫代碼一致。一、CORS控制誰可以發(fā)起與交換 challengeCap Standalone 默認(rèn)允許任意來源origin的網(wǎng)頁請求挑戰(zhàn)并完成挑戰(zhàn)交換這一默認(rèn)策略可以通過環(huán)境變量CORS_ORIGIN在啟動服務(wù)時覆蓋。默認(rèn)值*即允許所有 origin。多個 origin使用英文逗號分隔例如domain1.tld,domain2.tld,...。在源碼層面CORS_ORIGIN的解析邏輯位于 settings-cache.js當(dāng)值為*或未設(shè)置時解析結(jié)果為{ origins: null }等價于全部放行否則會先按逗號切分、去除空白與*條目得到一個白名單數(shù)組。該默認(rèn)值會在服務(wù)啟動時通過loadCorsDefault()載入內(nèi)存緩存見 index.js。CORS 的最終判定在 index.js 的elysiajs/cors插件中完成/assets及其子路徑始終放行資源需要被任意站點加載其余路徑交由checkCorsOrigin(request)判定其實現(xiàn)位于 settings-cache.js優(yōu)先使用每個 site key 的corsOrigins配置可在 APIPUT /server/keys/:siteKey/config中按鍵設(shè)置見 server.js未按鍵配置時回退到全局默認(rèn)即CORS_ORIGIN解析結(jié)果判定時既支持完整的Origin頭字符串精確匹配也支持僅傳host的寬松匹配判定結(jié)果在內(nèi)存中緩存 60 秒CORS_CACHE_TTL修改配置后通過invalidateCorsCache立即失效。從源碼結(jié)構(gòu)看這套機制同時支持全局白名單 按鍵白名單兩層覆蓋適合多站點共用一臺 Cap 的場景。二、Asset Server自托管 widget 與 WASM 靜態(tài)資源Cap Standalone 內(nèi)置一個靜態(tài)資源服務(wù)Asset server用于讓前端頁面不再依賴第三方 CDN 加載 widget 腳本與 WASM 二進制文件從而滿足隱私優(yōu)先、自托管的要求。2.1 開啟與版本鎖定Asset server默認(rèn)關(guān)閉需要顯式設(shè)置環(huán)境變量開啟ENABLE_ASSETS_SERVERtrue WIDGET_VERSION0.1.58 WASM_VERSION0.0.8ENABLE_ASSETS_SERVER置為true后資源將從/assets端點對外提供WIDGET_VERSION與WASM_VERSION必須與你希望托管的 widget / WASM 文件版本一致可用的版本號即 npm 上cap.js/widget與cap.js/wasm的發(fā)布版本兩者默認(rèn)值均為latest會提供最新版本但不建議在生產(chǎn)環(huán)境使用——小版本更新可能帶來破壞性變更導(dǎo)致線上系統(tǒng)突然不可用。對應(yīng)源碼實現(xiàn)見 assets.js只要ENABLE_ASSETS_SERVERtrue且任一版本為latest啟動時就會打印警告日志提醒生產(chǎn)環(huán)境應(yīng)固定版本號。2.2 資源路徑與前端接入方式開啟后文件會從以下路徑對外提供對應(yīng)路由實現(xiàn)在 assets.js/assets/widget.js—— 標(biāo)準(zhǔn) widget 腳本/assets/floating.js—— 浮動模式floatingwidget 腳本/assets/cap_wasm_bg.wasm—— 主 WASM 二進制/assets/hashwx.wasm—— HashWX 專用 WASM/assets/cap_wasm.js—— WASM 加載器loader前端接入時把script的src指向你服務(wù)器的對應(yīng)路徑即可例如script srchttps://server url/assets/widget.js/script浮動floating模式則使用script srchttps://server url/assets/floating.js/script同時將window.CAP_CUSTOM_WASM_URL與window.CAP_CUSTOM_HASHWX_URL分別指向cap_wasm_bg.wasm與hashwx.wasm讓 widget 從你的服務(wù)器加載 WASM 而不是第三方 CDNwindow.CAP_CUSTOM_WASM_URL https://server url/assets/cap_wasm_bg.wasm; window.CAP_CUSTOM_HASHWX_URL https://server url/assets/hashwx.wasm;需要特別注意一個版本邊界hashwx.wasm從cap.js/wasm0.0.8 起才存在。如果WASM_VERSION指向更早的版本/assets/hashwx.wasm會返回503。此時不要設(shè)置CAP_CUSTOM_HASHWX_URLwidget 會自動改從 jsdelivr 加載該文件這一回退邏輯同樣體現(xiàn)在 assets.js當(dāng)拉取hashwx.wasm失敗時會打印警告并刪除緩存鍵。2.3 資源來源CACHE_HOST默認(rèn)情況下上述文件在服務(wù)啟動時從process.env.CACHE_HOST拉取該變量默認(rèn)值為https://cdn.jsdelivr.net可在啟動服務(wù)時通過設(shè)置CACHE_HOST替換為任意可訪問的鏡像或自建源對應(yīng)實現(xiàn)見 assets.js資源 URL 形如${CACHE_HOST}/npm/cap.js/widget${WIDGET_VERSION}與${CACHE_HOST}/npm/cap.js/wasm${WASM_VERSION}/browser/...文件被下載后寫入 Redis鍵名如asset:widget.js、asset:cap_wasm_bg.wasm等隨后由/assets/*路由從 Redis 讀出并提供給客戶端資源路由還會附加Cache-Control: max-age31536000, immutable響應(yīng)頭assets.js便于瀏覽器長期緩存。2.4 常見故障排查若訪問某個資源端點得到Asset not cached yet的響應(yīng)說明文件尚未成功下載到 Redis 緩存該響應(yīng)對應(yīng)路由內(nèi)緩存缺失時返回的503見 assets.js。請按以下順序檢查確認(rèn)容器內(nèi)真的設(shè)置了ENABLE_ASSETS_SERVERtrue如果你在 compose 文件中修改了該值需要重建容器使其生效否則/assets/*會返回404并附帶說明 Asset server is disabled見 assets.js。確認(rèn)容器可以訪問CACHE_HOST若下載失敗啟動時日志中會打印包含[asset server] failed to update assets cache的行之后每1 小時重試一次setInterval(updateCache, 1000 * 60 * 60)見 assets.js。確認(rèn)WIDGET_VERSION與WASM_VERSION指向 npm 上真實存在的版本版本號不存在時拉取必然失敗同上記錄錯誤日志。補充一點緩存刷新機制updateCache會讀取 Redis 中的asset:cache-config只有距上次更新超過 1 天或WIDGET_VERSION/WASM_VERSION發(fā)生變化時才重新拉取assets.js因此鎖定版本后資源緩存是長期穩(wěn)定的。三、請求限流按客戶端 IP 的固定窗口Challenge 相關(guān)端點按客戶端 IP 進行限流采用固定時間窗口fixed window算法。3.1 默認(rèn)值與調(diào)整方式默認(rèn)限制每個 IP 每 5 秒最多 30 次請求全局調(diào)整在儀表盤Settings頁面修改或通過 APIPUT /settings/ratelimit設(shè)置按鍵覆蓋在某個 site key 的Configuration標(biāo)簽頁中可為該鍵單獨設(shè)置ratelimitMax與ratelimitDuration超限響應(yīng)返回 HTTP429并帶響應(yīng)頭X-RateLimit-Remaining: 0。以上默認(rèn)值max: 30, duration: 5000與 API 校驗范圍max1–10000、duration1000–3600000 毫秒在 server.js 中有完整定義。限流核心實現(xiàn)在 ratelimit.js窗口鍵形如rl:{scope}:{ip}:{windowMs}:{window}通過 RedisINCR計數(shù)、首次計數(shù)時EXPIRE設(shè)置窗口過期響應(yīng)頭同時包含X-RateLimit-Limit與X-RateLimit-Remaining超過max時返回429與{ error: Rate limit exceeded }支持getLimits回調(diào)實現(xiàn)按 site key 讀取各自的限流參數(shù)對應(yīng)Configuration 標(biāo)簽頁按鍵覆蓋。3.2 siteverify 端點不受限流/siteverify端點專為服務(wù)器到服務(wù)器server-to-server的驗證設(shè)計默認(rèn)不參與限流。對應(yīng)的端點實現(xiàn)見 siteverify.js它接收secret與response參數(shù)校驗密鑰與一次性 token 后返回{ success: true }。3.3 代理背后的客戶端 IP 識別Standalone 識別客戶端 IP 時依次檢查以下請求頭X-Forwarded-ForX-Real-IPCF-Connecting-IP全部缺失時才回退到 socket 層地址。這一順序在 ratelimit.js 的DEFAULT_IP_HEADERS常量中原樣體現(xiàn)實現(xiàn)還處理了逗號分隔的鏈?zhǔn)街等〉谝粋€條目。如果你位于使用其他請求頭的反向代理之后有兩種方式指定 IP 來源設(shè)置環(huán)境變量RATELIMIT_IP_HEADER例如位于 Cloudflare 之后時可設(shè)為cf-connecting-ip或在儀表盤Settings Headers中配置 IP 頭。以 nginx 為例務(wù)必確保代理把真實客戶端 IP 傳給 Caplocation / { proxy_pass http://localhost:3000; proxy_set_header X-Forwarded-For $remote_addr; }兩個必須警惕的后果如果不轉(zhuǎn)發(fā)真實 IP所有請求都會被視為來自代理自身 IP所有客戶端將共享同一個限流配額桶等于限流失效X-Forwarded-For等頭部按原樣被信任。因此服務(wù)器絕不能直接暴露在公網(wǎng)否則客戶端可以偽造頭部繞過限流代碼邏輯見 ratelimit.js它無條件信任這些頭。四、Redis / Valkey全部持久化依賴Cap Standalone 的所有持久化數(shù)據(jù)site key、配置、會話、令牌、指標(biāo)、資產(chǎn)緩存等都存儲在 Redis或其兼容替代品 Valkey中。連接配置設(shè)置環(huán)境變量REDIS_URL為你的 Redis 連接字符串默認(rèn)值為redis://localhost:6379Valkey 推薦官方快速開始指南推薦通過 docker-compose 使用 ValkeyRedis 兼容存儲多實例隔離如果多個 Cap 實例或其他應(yīng)用共用同一個 Redis 實例應(yīng)設(shè)置REDIS_PREFIX為所有鍵添加命名空間前綴。例如REDIS_PREFIXcap:后會話鍵存儲為cap:session:...、指標(biāo)鍵存儲為cap:metrics:...。默認(rèn)值為空字符串因此已有部署不會受到影響。對應(yīng)源碼見 db.js連接 URL 實際是REDIS_URL || VALKEY_URL || redis://localhost:6379的三級回退REDIS_PREFIX通過一個 Proxy 包裝所有 Redis 命令自動為get/set/hget/hmset/sadd/incr/expire等鍵名前置前綴KEY_FIRST/KEY_ALL兩組命令集合見 db.js讀取KEYS結(jié)果時還會反向剝離前綴。此外 db.js 還實現(xiàn)了連接中斷自動重連檢測到連接類錯誤碼時以指數(shù)退避500ms 起、上限 15s重新建立連接并對重連前的操作進行一次性重試增強了自托管場景下的可用性。五、健康檢查與優(yōu)雅關(guān)閉Cap Standalone 提供兩個無需認(rèn)證的端點供容器編排系統(tǒng)與監(jiān)控告警使用。5.1 /health 與 /health/liveGET /health當(dāng) Redis 在2 秒內(nèi)響應(yīng)PING時返回200 {status:ok}否則返回503 {status:unavailable}。用于 readiness check就緒探針與告警GET /health/live只要進程存活就返回200即使 Redis 已宕機。用于 liveness check存活探針避免 Redis 故障期間編排系統(tǒng)反復(fù)重啟 Cap。同秒內(nèi)到達(dá)的健康檢查會復(fù)用同一次 PING因此頻繁調(diào)用/health不會給 Redis 增加額外負(fù)擔(dān)。源碼實現(xiàn)在 health.jsREDIS_TIMEOUT_MS 2000對應(yīng) 2 秒超時REDIS_CHECK_REUSE_MS 1000對應(yīng) 1 秒內(nèi)的結(jié)果復(fù)用/health/live是無條件返回ok的純靜態(tài)端點。5.2 Kubernetes 探針示例readinessProbe: httpGet: path: /health port: 3000 livenessProbe: httpGet: path: /health/live port: 30005.3 Docker Compose 健康檢查若使用 Docker Compose可在cap服務(wù)中追加以下配置。注意純 Docker 模式只會把容器標(biāo)記為 unhealthy不會自動重啟healthcheck: test: [CMD, bun, -e, fetch(http://127.0.0.1:3000/health).then((r) process.exit(r.ok ? 0 : 1)).catch(() process.exit(1))] interval: 30s timeout: 5s retries: 35.4 SIGTERM / SIGINT 優(yōu)雅關(guān)閉行為收到SIGTERM或SIGINT時Cap 會停止接受新連接等待正在處理的請求完成關(guān)閉 Redis 連接以退出碼0正常結(jié)束。若 8 秒后仍有請求在運行則立即以退出碼1結(jié)束——因此總能落在 Docker 默認(rèn) 10 秒停止時限之內(nèi)如果在關(guān)閉過程中再次收到信號則直接立即退出。上述邏輯與常量SHUTDOWN_TIMEOUT_MS 8000在 index.js 與 index.js 中完整實現(xiàn)。另外兩個部署相關(guān)的環(huán)境變量也值得留意SERVER_PORT默認(rèn)3000與SERVER_HOSTNAME默認(rèn)0.0.0.0。六、錯誤消息默認(rèn)脫敏按需開啟詳情錯誤響應(yīng)默認(rèn)脫敏——內(nèi)部錯誤細(xì)節(jié)不會出現(xiàn)在響應(yīng)體中而是記錄到控制臺日志同時響應(yīng)會附帶一個隨機錯誤 IDBun.randomUUIDv7()的尾部片段便于在日志中檢索。兩個開關(guān)控制該行為DISABLE_ERROR_LOGGINGtrue關(guān)閉錯誤日志輸出SHOW_ERRORStrue關(guān)閉消息脫敏把完整的錯誤序列化詳情名稱、消息、堆棧、錯誤碼、原因暴露在響應(yīng)體detail字段中。對應(yīng)實現(xiàn)見 index.js 的全局onError處理器VALIDATION與NOT_FOUND兩類錯誤默認(rèn)不寫日志其余錯誤默認(rèn)打印結(jié)構(gòu)化日志含時間戳、Bun 版本、平臺與內(nèi)存快照并把troubleshooting指引指向本文檔對應(yīng)章節(jié)。七、HashWXGPU 抗性的默認(rèn) PoW 協(xié)議7.1 協(xié)議與默認(rèn)行為Standalone 以HashWX作為新建 site key 的默認(rèn) challenge 協(xié)議。HashWX 是 Cap 的 GPU 抗性 proof-of-work與固定哈希函數(shù) SHA-256 不同它每個 challenge 都基于 seed 生成一個全新的單向函數(shù)由整數(shù)運算與分支構(gòu)成使得 GPU 相對 CPU 幾乎沒有吞吐優(yōu)勢。三個關(guān)鍵特性按鍵獨立協(xié)議是按 site key 單獨設(shè)置的因此可以出現(xiàn)部分鍵用 SHA-256、部分鍵用 HashWX 的混合狀態(tài)舊鍵不受影響在 HashWX 成為默認(rèn)值之前創(chuàng)建的鍵會保留原有協(xié)議直到你手動更改無需密鑰對HashWX 不要求生成或保存任何密鑰對配置成本為零。切換方式打開該 site key 的Configuration標(biāo)簽頁在Challenge protocol下選擇所需協(xié)議即可。對應(yīng)的默認(rèn)配置在 server.js 的keyDefaults中定義protocol: hashwx、hashwxDifficulty: 1_000_000API 層允許的協(xié)議值為sha256-pow、rsw、hashwx三選一server.js。7.2 難度配置與設(shè)備耗時參考HashWX difficulty滑條控制難度其數(shù)值含義是預(yù)期客戶端需要執(zhí)行的哈希次數(shù)默認(rèn)值1_000_000被拆分為4 個子挑戰(zhàn)sub-challenges實測參考8 核桌面 Chrome 上中位數(shù)約578 毫秒手機上約1.1 到 5.9 秒調(diào)高難度前務(wù)必先參考 hashwx.md 中的手機實測數(shù)據(jù)取值范圍50_000到5_000_000。上述取值范圍與默認(rèn)值同樣在 server.js 的 API 校驗層minimum: 50000, maximum: 5000000與配置默認(rèn)值中原樣體現(xiàn)。7.3 WebAssembly 前提與回退方案無法運行 WebAssembly 的客戶端無法求解 HashWX challenge。如果需要兼容這類客戶端請把該鍵切換為SHA-256 PoW——它提供純 JavaScript 實現(xiàn)作為回退路徑。作為對比cap-core非 Standalone 場景默認(rèn)仍使用 SHA-256 PoW除非顯式開啟參見 capjs-core 的 HashWX 說明。7.4 已廢棄的 RSW time-lockRSWRivest-Shamir-Wagner time-lock 謎題仍然可以對存量部署按鍵啟用但已廢棄GPU 每秒可求解的數(shù)量約為 CPU 的170 倍無法提供設(shè)計初衷所期望的 GPU 抗性。相關(guān)配置RSW difficulty滑條設(shè)置參數(shù)t需要順序執(zhí)行的平方運算次數(shù)范圍10_000–300_000默認(rèn)75_000見 server.js 的rswT默認(rèn)值及其校驗范圍 server.jsRSW_BITS2048用于在啟動時覆蓋 RSA 模數(shù)的位寬對應(yīng) rsw-store.js 中的密鑰對加載與刷新邏輯。小提示widget 能夠根據(jù)數(shù)據(jù)格式自動檢測挑戰(zhàn)協(xié)議因此當(dāng)你調(diào)整鍵的協(xié)議時唯一需要做的就是切換鍵本身無需修改前端代碼。八、Instrumentation 挑戰(zhàn)攔截自動化與 headless 瀏覽器除了 PoWCap Standalone 還支持JavaScript instrumentation challenge用于應(yīng)對能自動求解 proof-of-work 的攻擊者并可選擇性地攔截 headless 瀏覽器默認(rèn)開啟新建 site key 時instrumentation challenge 默認(rèn)啟用對應(yīng) server.js 中instrumentation: false為 API 入?yún)⒛J(rèn)而儀表盤新建流程會開啟它配置結(jié)構(gòu)支持每個鍵獨立開關(guān)開關(guān)位置在 site key 的設(shè)置頁面中開啟或關(guān)閉攔截 headless如需屏蔽 headless 瀏覽器在該鍵設(shè)置中打開Attempt to block headless browsers對應(yīng)配置字段blockAutomatedBrowsers見 server.js混淆級別obfuscationLevel默認(rèn)3取值范圍 1–10server.js。官方建議保持級別 3除非你需要更強的混淆效果過高的級別會顯著降低成功率。如果覺得級別 3 太慢級別 1 在單核上會快得多。九、IP 數(shù)據(jù)庫國家與 ASN 歸屬查詢Cap Standalone 的統(tǒng)計與地理功能依賴 IP 歸屬查詢支持在儀表盤Settings IP Data Country ASN data中從三個提供商中選擇DB-IP Lite免費無需憑據(jù)自動嘗試最近 3 個月的數(shù)據(jù)文件MaxMind GeoLite2需要 MaxMind 賬戶 ID 與 License Key通過 Basic Auth 下載 tar.gz 并解包出.mmdbIPInfo API需要 API token走遠(yuǎn)程 HTTP 查詢本地不落地文件。對于 DB-IP 與 MaxMind.mmdb文件會被下載到容器內(nèi)的/usr/src/app/data/目錄。對應(yīng)實現(xiàn)見 ipdb.jsDATA_DIR指向standalone/data在容器中即/usr/src/app/data下載、解壓、進度上報與每 2 小時重載RELOAD_INTERVAL的完整流程均在該文件中。Docker volume 權(quán)限問題容器以非特權(quán)用戶bunUID 1000運行見 Dockerfile 的USER bun。如果你把宿主機目錄 bind-mount 到/usr/src/app/data該目錄必須允許 UID 1000 寫入否則下載會失敗并報EACCES: permission denied。正確做法mkdir -p ./cap-data sudo chown 1000:1000 ./cap-dataservices: cap: image: tiago2/cap:latest volumes: - ./cap-data:/usr/src/app/data # ...如果無法修改宿主機文件屬主部分平臺如 Coolify 操作起來較麻煩最簡單的替代方案有三個不做 bind mount讓 Docker 管理數(shù)據(jù)目錄——鏡像在構(gòu)建時已創(chuàng)建好目錄并設(shè)置了正確屬主Dockerfile 中的mkdir -p data chown bun:bun data改用named volume代替 bind mount切換到無需本地文件的 IP 數(shù)據(jù)提供商即 IPInfo API 模式。值得補充的是ipdb.js 啟動時會對數(shù)據(jù)目錄做可寫性探測寫入并刪除.write-test文件失敗時會直接輸出包含chown 1000:1000建議的錯誤日志方便你在容器日志中第一時間定位該問題?？偨Y(jié)生產(chǎn)部署配置速查結(jié)合本文與源碼一份自托管生產(chǎn)部署的最小關(guān)注清單如下關(guān)注點環(huán)境變量 / 配置默認(rèn)值生產(chǎn)建議跨域CORS_ORIGIN*收窄為你的域名白名單靜態(tài)資源ENABLE_ASSETS_SERVER關(guān)閉自托管時置true資源版本W(wǎng)IDGET_VERSION/WASM_VERSIONlatest固定到已發(fā)布的具體版本資源來源CACHE_HOSTjsdelivr CDN可替換為自建鏡像限流儀表盤或PUT /settings/ratelimit30 次 / 5 秒按業(yè)務(wù)峰值調(diào)整勿直接暴露公網(wǎng)代理 IPRATELIMIT_IP_HEADER或 Settings Headers標(biāo)準(zhǔn)三頭按代理類型設(shè)置并確保轉(zhuǎn)發(fā)真實 IP存儲REDIS_URLredis://localhost:6379生產(chǎn)建議獨立實例多實例隔離REDIS_PREFIX空共享實例時務(wù)必設(shè)置健康檢查/health、/health/live—接入編排系統(tǒng)探針挑戰(zhàn)協(xié)議每鍵 ConfigurationHashWX按客戶端兼容性選擇混淆級別obfuscationLevel3保持 3慢則降 1IP 數(shù)據(jù)目錄/usr/src/app/data—bind mount 時確保 UID 1000 可寫若需從頭部署請結(jié)合 Cap Standalone 快速開始指南含 Valkey 的 docker-compose 配置與 API 文檔 一起閱讀HashWX 協(xié)議的設(shè)計原理與成本實測可繼續(xù)參考 HashWX 詳解。贊分享網(wǎng)絡(luò)安全應(yīng)用安全后端【免費下載鏈接】capFree, open-source and self-hosted CAPTCHA alternative to reCAPTCHA. Privacy-first and powered by proof-of-work and instrumentation challenges.項目地址https://gitcode.com/gh_mirrors/cap13/cap點擊查看免費下載相關(guān)推薦Cap Standalone 配置指南CORS、資源服務(wù)器、限流、健康檢查與挑戰(zhàn)協(xié)議全解析Cap Standalone 配置指南CORS、資源服務(wù)器、限流、健康檢查與挑戰(zhàn)協(xié)議全解析 Cap Standalone 是 Cap https://link網(wǎng)絡(luò)安全應(yīng)用安全后端Cap Standalone 配置完全指南CORS、Asset Server、限流與 HashWX Proof-of-Work 環(huán)境變量詳解Cap Standalone 配置完全指南CORS、Asset Server、限流與 HashWX Proof of Work 環(huán)境變量詳解 Cap Stan網(wǎng)絡(luò)安全應(yīng)用安全后端Cap Standalone 配置選項與環(huán)境變量完全指南CORS、資源服務(wù)器、限流、健康檢查與哈希工作量證明Cap Standalone 配置選項與環(huán)境變量完全指南CORS、資源服務(wù)器、限流、健康檢查與哈希工作量證明 本篇技術(shù)指南以 Cap Standalone開網(wǎng)絡(luò)安全應(yīng)用安全后端上一篇Arnis終極部署指南5種環(huán)境配置策略與高效管理技巧下一篇最全面Manim版本解析社區(qū)版vs原版核心差異與選擇指南創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考