這件事情是這樣的，iN自己雖然不弄在家裡弄NAS什麼的，但是還是會有在家看視訊的需求的。同樣也很懶，懶得各種論壇搜尋下載下傳資源。是以就在家做了一個視訊站點，通過源搜刮的功能來收集視訊源。
這件事很多很多人都會做，也沒必要寫什麼教程。
不過，有的時候會因為網絡封堵的問題導緻一些視訊源不太通暢，這不最近幾天《慶餘年2》在收集的時候由于這個劇太火，導緻了源URL的當機，丢在VPS上的伺服器也就搜尋不到任何資源了……
這件事實際上來源于各種服務API端口的限制。
怎麼整？
我們是可以利用cloudflare的Worker來處理的。方法就是簡單的給我們的URL請求加個殼。
說下原理：
大部分基于各種URL的API通常都并不會很在意源請求位址是什麼，但是往往很頻繁請求的源往往會被block掉。這就導緻我們在通過web用戶端去調用的時候出現錯誤。
同樣，大多數基于WEB API的内容是可以修改的，如果被修改後往往會引入不安全的問題。
對于這種現象，我們可以利用網絡工具給請求的目标加個“殼子”，确切說就是URL轉發——把我們要請求的URL位址發送到自己制作的一個Worker腳本中，然後再讓這個Worker腳本去請求真正的服務，請求的結果再通過Worker傳回我們自己的伺服器中。
說到這裡Worker的概念大家可以有一個模糊的架構了——Cloudflare Workers 是一種邊緣計算技術，使開發者能夠在 Cloudflare 的全球網絡上運作 JavaScript 代碼。與傳統的伺服器托管不同，Cloudflare Workers 允許在離使用者最近的地點執行代碼，進而提高響應速度和性能。
我們說的“加個殼”，實際上在網絡中屬于一種邊緣計算，利用Woker可以将資料處理和計算資源分布在網絡的邊緣節點，而不是集中在家裡的NAS或者資料中心的的VPS中。
由于加了一個中間的處理層，我們就可以在源資料和服務之間再做一層判定來提高安全性。同時大部分Worker本身是不固定IP位址的，對于Web API的通路也可以避免因為通路過于頻繁封IP的問題。
要實作這個功能，這樣做：
前提條件：
1.你有一個cloudflare賬戶可以建立Worker
2.你有需要通路的WEB API位址。
非充要條件：稍微會一點js腳本知識。
做法：
進入cloudflare控制台，到Worker設定中建立一個新的Worker
給Worker命名：
這個名字就是一個好記的，你可以快速識别出來的标記名稱，通路Worker的時候也是通過這個名字做辨別的。
同時在代碼預覽中cloudflare會生成一個簡單的hello world腳本，讓我們部署好的Worker至少可以傳回一些資訊。
在這個界面沒有必要做任何其他修改，直接點選部署按鈕我們就可以部署出一個Worker腳本。
在首次部署成功後，我們就可以利用編輯代碼的按鈕對剛剛建立的Worker進行代碼編輯
進入代碼編輯器中，cloudflare提供了一個簡單的代碼編寫環境，分三個部分
1:代碼編寫
2.請求發送
3.結果
例如iN今天做的視訊采集的Worker，隻有幾行代碼：
原理很簡單，将請求到這個Worker上的URL參數讀取出來，然後替換給targetUrl，再經過fetch（targetUrl）的方法取得原始的WEB API應該傳回的資訊。這時候，就能拿到原始Web API的回複，再将回複原封不動的傳遞給我們自己的伺服器或者NAS就可以了。
将原始API所需要的參數重網址部分，替換為我們自己的的Worker的位址，保留原始參數不變，就可以工作起來了。
原始API URL的形式： AAAAA/參數
Worker的主機：CCCCC
改變後的形式：CCCCC/參數
就這麼簡單。
說好處：
首先是隐蔽了我們自己主機的位址，畢竟目前提供API的很多組織或個人還是不太可信的，沒必要讓對方知道我們自己的IP
其次，速度快，由于Worker是建立在CDN網絡中的，在全球各個位置都有自己的鏡像，是以對于Worker到目标的網絡距離要遠小于我們自己的主機到目标的距離。這就保證的通路速度。
再次，目标API的内容是可以審計的。在到達我們自己系統之前我們可以利用程式審計一下傳回内容，然後再加入自己的系統。這樣的安全性可以提高一下。
最後說下費用：10萬次/日免費，對于一般家用和個人使用很難在一天内發出10萬次的通路量。目前使用了半年多的Worker還沒有因為這個功能付過費呢！