如果哪天有hacker進入到了公司內網為所欲為，你一定激動地以為這是一次蓄謀已久的APT，事實上，還有可能只是某位粗線條的員工把VPN信息泄露在了Github上恰巧被一個好奇的計算機junior發現了而已。
先貼張圖：
有記者給溧陽衛生局局長撥通電話，該局長面對記者的采訪慌張答道：
“你看到我們發微博的啊？呵呵，你怎么看到的啊？這個都能看得到啊？！這不可能吧？我們兩個發微博你都能看得到啊？不可能吧？”……
同樣，互聯網企業的員工流動性很強，各自的安全（隱私）意識也參差補齊。龐大的企業難免有些人由于無知或由于偷懶把含有敏感信息（如數據庫連接串，郵箱賬號，VPN信息）的代碼直接丟到github上去。如果這些信息被有心人看到了，那就能讓黑客花最小的成本，達到APT的效果了。
另附一篇漏洞盒子關于github泄露企業機密信息的報告：
https://www.vulbox.com/news/detail-15
于是，我們想實現github代碼的監控，定制諸多關鍵詞如password，mysql，account，email，希望通過爬蟲程序來實現對github上敏感代碼的監控，如果有可疑信息泄露，程序通過郵件通知負責人，負責人去進行二次人工審核。這樣，能在第一時間發現敏感代碼的泄露，并及時聯系提交者進行處理。
期望是美好的，但是在連續高頻訪問若干次github.com之后：
觸發了github的反爬機制，難道項目要流產？
機智的樓主想起之前團隊購買了5臺阿里云機器，何不用阿里云機器搭建一套代理實現分IP訪問繞開反爬機制？
于是就有了下圖。
一次敏感代碼爬取的流程：
請求發送到負載均衡Nginx，Nginx將請求按照同權重的方式轉發到流量轉發Nginx
注：負載均衡Nginx設置為兩臺，防止出現單點故障。
收到負載均衡Nginx發過來的流量，流量轉發Nginx將請求轉想github.com
github.com返回的內容通過Nginx原路返回給Github爬蟲引擎
這樣，對于github.com而言，他看到的是三臺機器在一樣頻率的交替訪問，頻率是原先的1/3，巧的是，這個頻率就不會觸發反爬機制。從而實現了Github爬蟲引擎的連續訪問，效率大大提升。
同時，這套方案的擴展性還很強，如果再次被github.com反爬機制封鎖，可以通過平行加流量轉發Nginx機器的方式來實現水平擴展。
附負載均衡Nginx的核心配置：
附流量轉發Nginx的核心配置：
