把桌面和文檔存儲路徑改為 D 盤，然後隨心所欲。
重要的文檔每隔一周發一次去文件傳輸助手，直到不再重要為止。

看了你前前後後的帖子，大概知道你想幹嘛。
但是真的如#13 樓的說法，建議先了解 http 協議和一些基礎的 tcp 協議。
Response 響應裡面，Nginx 默認情況下是沒有攜帶域名字符的，除非你自己 add_header 進去或者有用 Set-Cookie 設置進去。

另外你的問題是被墻了，然後你覺得 GFW 是根據回來時候的域名匹配，然後攔截了返回來的數據。
其實你想多了，
出去的時候數據就被標記了，返回的時候就直接劫持。GFW 並不是根據“返回”域名，而是過去的時候就標記好了註定回不來了。
你可以嘗試使用 IP 訪問(如果 IP 沒被 block 的情況下)，如果能正常訪問，那你去 nginx 通過 add_header 把域名加進去，你看看是不是依然可以返回。

最後，GFW 不是我弄的，我不敢 100%和你打包票，但是 5 年前就已經聽說過，GFW 已經是旁路形式存在，然後對敏感數據進行標記，標記達到多少次後直接劫持走，如果存在黑名單字詞就直接丟黑洞。

什麼叫“服务器往访问客户发送的数据包中域名”？
是 response 中的數據還是 body 中的數據？

@JustinJie java 不清楚，我是直接 PHP 跑腳本
主進程讀 1K 條就 fork 個子線程出來跑插入，
然後插入失敗就寫個 log （完整的 SQL 語句），
最後在跑一次失敗 log 裡面的記錄。

因為是一年前的事，大概就這些，
你的環境我不清楚，我當時是異地的，數據量不算大，好像幾十萬筆記錄，

注意下網絡超時和新數據庫的格式就可以了（ mysqlmax_allowed_packet,還有 MYSQL 特性是否一致）。
對了，mysql 還有個 max_connections。

實話實說，你不缺時間的就一條條跑，失敗的記錄起來，然後打牌的打牌，喝酒的喝酒，跳舞的跳舞，每個一會看看有沒出錯就可以了。最後跑完就看看失敗的 log 裡面有沒 SQL 語句記錄，數量不多直接就在新數據庫裡運行裡面的語句。

good luck

@JustinJie 沒時間要求就一條條，有時間要求就嘗試讀 N 條，插入 N 條 異步操作。

表有區別就不能跑同步了，
就算是 dump 出來，你也 source 不了進去。
所以老老實實寫腳本。
具體點就是：
1、寫腳本，建測試庫
2、測試腳本用測試庫的資源。
3、和後端商議個時間做切換。
4、鎖庫腳本同步數據
5、後端切換數據
6、測試下
7、休息

GOV 網站大多數都是開普承擔。

@megamilk 我用了 3 個月餓了麼，實在無法忍受這平台，已轉美團很久了。餓了麼也卸了。
@tedcon 建議你也別洗地了，單在 V2EX 這個帖子裡，已經有那麼多人對你們有意見，你覺得市場外面的滿意度是怎樣？客滿就是客戶滿意度部門吧？我覺得最終年終會議，他們肯定把滿意率“做”到很高。等他們真正解決問題？呵呵

我試過幾次等了 2 個多小時最後換來一個系統取消訂單！！！
也試過騎手提前點送達！！！
更加試過寫著騎手專送最後變成了外包配送或者店鋪配送，等的那個時間真是餓到不餓了！！！
對了，還有你們的 UI，提過幾次 bug，但是你們客服基本不理，只是問句是點不了餐嗎？

這麼說吧，
如果你直接修改提交的內容，但是 signature 不改，微信那邊驗簽的時候直接就不通過了，因為你需要用被修改的數據重新跑一次加密的過程，才能得出正確的 signature （微信也是用得到的數據根據相同的公式進行簽名，再對比簽名是否一致）
為什麼需要隨機字符和時間截加進去，就是為了進行數據混餚，增加解密難度（解出 appsecret 的難度）。


後期為何綁定 IP，
那是因為太多人的 appid 和 appsecret 洩露出去了。

@leiuu
微信驗證方式：
比如提交數據是：
name="abc"
age = 18

假設 appid : 12345678
假設 appsecret: abcdefg

此時根據時間生成一個 timeStamp = 123456789
隨機生成一串字符：nonseStr = a456sdf

簽名方法：
根據排序，文本合併：
signature = md5('age=18&appid=12345678&name=abc&noseStr=a456sdf'.abcdefg)//大致這樣吧具體忘記了

然後可以得出，
如果篡改上面任意一個參數，最終的 signature 內容是不符的。
上面條件，只有 age,name,timeStamp,nonseStr 是別人知道的，缺少了 appid 和 appsecret 兩個參數，
因為 timeStamp 是一直變的，nonseStr 也是隨機生成的，如果通過截包方式猜測 appid 和 appsecret 明顯困難。（當然不排除有人直接固定 timestamp 和 nonseStr 的內容）
所以就算 signature 或者 每次的請求被人攔截了，想篡改數據可能不大。

為什麼後面微信會有個白名單驗證呢。
那是因為有很多開發者把 appid 和 appsecret 都丟上 github 去了。
所以後面開通的公眾號獲取 accessToken 都要設置 IP 白名單。

ememe，沒什麼好扯的， @l4ever 所說沒大問題，安全事項肯定要注意。
我想表達的是你參考微信，當初 oauth 就可為何後面加入百名單。
按時間計算 5s 内的时间戳有效 這個方式有個平台在用，他們的技術給人罵到不敢吭聲。（你想象下網絡的延遲和時間的不同步問題因素），後來他們技術改為時間不一致後返回相差時間。（不用想了，又被人噴了一次，既然你都返回相差時間，你 TM 還不如直接跳過這個驗證？）

如有可能 IP 白名單即可了。不用那麼多花花綠綠的。

具體不是很清楚，不過看你香港節點，速度去到 11MB/S，你究竟是什麼人，國際帶寬過 100M，要不你建個梯子，我們大家一起幫你測試下

@l4ever appid appsecret 洩露出來，現在好像也沒什麼危害了吧...
微信 JSSDK 或 Oauth 現在需要自行配置業務域名和 IP 白名單。

這麼說吧，
假設你的瀏覽器高度寬度固定值是 800 *600 像素
那麼你去到 2K，4K 屏幕也好，你的像素永遠是 800*600
然後根據相對的尺寸（瀏覽器內文距離頂部 X 截圖到瀏覽器內文距離右邊的 Y ）截圖
出來的結果就不會受到你電腦的分辨率影響。

可是你可以用相對坐標獲取吧？
selenuim 真的不熟悉，
如果是 electron 的話，直接 set 絕對的寬高（像素），
然後通過 set 好了的寬高像素進行相對定位。
那樣無論去到什麼屏幕你提取出來的都一樣。

@NGPONG 我也不是一個扎實的前端，只是有段時間因為某些原因所以接觸過。
我當時遇到的問題和你現在的問題差不多，但我們需求不一致。
媒體查詢：根據不同分辨率設備設置不同的樣式。等於一個網頁根據不同分辨率就寫一次，具體些多少次要看你適配的精度。適配精度越高，寫的 CSS 越多。
“具体点来说的话就是我做的是 OCR，截取当前浏览器所显示的内容（截取功能由 selenuim 提供出来）并在相应的坐标读取一些内容。”
大致明白你要做什麼，類似腳本的外掛對屏幕定位讀取血條計算百分比是否需要吃紅 吧？
selenuim 說實話不熟悉，不清楚你實際需求，但根據你所說的，會不會用 electron 寫，注入 JS 進行定位你需要的目標 dom，然後提取出來進行 OCR 識別會方便一點呢？

@NGPONG 好的，其實問題的核心應該是 物理尺寸 和 屏幕像素 的轉換關係吧？
你沒說是用什麼寫的，我權當 css 吧，
在不同分辨率下，顯示效果的物理尺寸相同，實現的方式只能靠百分比進行了，(當然，你獲取屏幕 dpi 和分辨率後進行換算，其實和百分比實現的方式是一樣的)。但是文字等比放大的問題你怎麼處理？而且這樣設計出來的界面會很彆扭，為什麼彆扭？因為你的素材肯定要選個固定像素的吧？我當你選擇 2K 的素材，那麼去到 4K 的時候，你的素材是進行了等比放大，換句話說就是毛孔都出來了，另外還要考慮寬屏和正屏的問題。然後你會想那我就直接用 4k 作為素材，此時如果用戶是 800*800 的屏，那你上面的文字是縮小到有多小啊？
我不知道你是用什麼設計界面，
但是在 css 裡有個媒體查詢，根據不同的分辨率進行不同的匹配。
偷懶點的做法還可以設定一個像素固定值，屏幕大的兩邊空，小過固定值的就滾動，保持用戶看到的就是設計者當初設計的模樣。

nginx 是 reload 和 start 時候把配置引用到內存裡的，並不是有訪問才讀取磁盤裡的配置文件。
所以你分多個配置和一個大的配置文件，對於後續的請求操作，是沒有影響的。

但是你說到 5000 個站點，請問都是靜態嗎？還是動態？還是你這個 nginx 只是做負載？
排除負載和動態，你確定你的服務器能支撐到嗎？