PTT數位生活區 / Facebook (臉書)

Re: [詢問] 最近臉書瀏覽照片的顯示圖片速度好慢

看板Facebook (臉書)作者時間9年前 (2015/10/25 22:07), 9年前編輯推噓6(6推 0噓 84→)
留言90則, 9人參與, 最新討論串2/2 (看更多)
我也來分享一下我所看到的現象 XD ※ 引述《s3103006 (累積分配)》之銘言： : 大家好 : 這篇是一個月前的了 : 我的fb到現在還是一樣 請問還有人跟我一樣的嗎? : 狀況如下: : 1. 照片都是白底跑不出圖片 一片白 有些照片會顯示 有些不會 當然 因為縮圖的網址是 https://fbcdn-photos-*-a.akamaihd.net/...... 之類的 這一群主機不知道為什麼 很容易會被DNS解析之後 引導你連線到國外的主機 而HiNet非固定制的網路 這兩個月在尖峰時間要連到這些主機很困難 原因不明 但如果很幸運的剛好解析出的IP 是要連到國內的主機 那個ping值大概只有10ms上下吧 不會掉封包 連線又很順暢 因此你會突然看到圖片顯示又變順了! 不過別高興太早 Chrome預設的DNS cache應該只有一~兩分鐘 因此cache過期之後 會再重新解析那些主機的IP 等於又要再抽一次獎了 若是抽到國外的主機 又要看到一堆空白的縮圖 XD 其它交叉比對的因素(線路/DNS等等)待我稍後說明 : 2. 去點跑不出來的圖片 一點就馬上可以看到內容 這個也有辦法解釋 點縮圖跳出大圖片(完整圖片) 它的網址是: https://fbcdn-sphotos-*-a.akamaihd.net/...... 這群主機在八月下旬一樣很容易會被解析到國外的主機 要你連線國外 然後就會遇到跟上面類似的問題! 不同的是 HiNet DNS後來變成較容易解析到台灣的節點 因此多數網頁元素顯示會恢復正常 但是縮圖還是會有問題 一樣引導你到國外 如果是用Google DNS就比較慘 直到最近還是蠻常解析到國外的主機 明明台灣就有節點 硬是要繞去線路品質不佳的國外 XD 所以如果你現在用的是HiNet DNS的話 除了縮圖以外的網頁元素應該都可以正常顯示! : 到現在斷斷續續已經快2個月了 : 還重灌了一次電腦 再裝了新的防毒 : 還是一樣沒有改善@@ : 我的系統環境如下: : 1.CPU i7 : 2.ram 16G : 3.瀏覽器:Chrome : 4.網路: 中華光世代 除了網路以外 跟其它的都沒關係 不是硬體問題 : 目前有聽說中華海底電纜好像出了問題 連到國外都會很慢 : 不知道有沒有可能是這樣 但斷掉2個月也有點久了.... : → sigurose: 如果改DNS為8.8.8.8、8.8.4.4（前提是DNS沒改錯位置，改 10/24 10:19 : → sigurose: 完後有重啟連線、或電腦有重開機），可以再嘗試手動清除 10/24 10:19 : → sigurose: Windows和Chrome的DNS Cache： 10/24 10:19 以最近Google DNS解析出來的結果(FB相關網站) 我是很不建議設定Google DNS 我以前也是8.8.8.8/8.8.4.4的愛好者 但它一直解析到國外的主機 然後線路品質一差 就會有一堆東西開不出來 XD 明明台灣有節點 別繞遠路呀 XD 不過這也不完全是Google DNS的問題 它有點被夾在中間 等一下會說 : → SPzero: 跟海纜問題無關喔！主要跟連到FB的CDN會繞到國外去情況有 10/25 10:02 : → SPzero: 關，建議還是先從DNS伺服器位址設定看看，像我設168.95.1. 10/25 10:03 : → SPzero: 1跟168.95.192.1到現在都一切正常，如果設定多組DNS都還是 10/25 10:04 : → SPzero: 無法解決問題的話，不然就打到412客服專線去嘗試反應看看 10/25 10:04 說跟海纜問題無關 我覺得有點不合理 因為每次當我的HiNet 100M/40M非固定制 又開始FB縮圖顯示不出來時(我用的是HiNet DNS) 馬上跳板到HiNet固定制線路或Google在彰濱機房的VM 順得跟什麼鬼一樣 XD DNS都沒改哦 DNS cache也還沒過期 只是連線走不同的路徑出去而已 所以是連到同一IP的機器 結果天差地遠 XD 所以就這個現象而言 我會比較傾向是這樣: (1) HiNet非固定制優先權較固定制低 因此連外線路因故有障礙時 可用頻寬不足 非固定制的品質就會被犧牲(當然 人家固定制付錢又不是付爽的)! 所以從這個點再往前推就是: 連外線路因故有障礙 可用總頻寬變少了 我想這才是關鍵 因為之前並不會這樣 XD DNS解析結果我覺得是另一個問題 如果用了Google DNS較容易解析出國外主機的IP位址 所以如果加上前面(1)的線路優先權&障礙的問題 解析出越多的國外主機IP位址 這個問題會更加嚴重!! 但如果你是HiNet固定制 或是像我一樣走Google自己的線路出去 就算是搭配Google DNS 然後解析出一堆國外主機IP位址 網頁開啟會稍微慢一點點(100ms上下) 但還是有在持續傳輸 而不是像非固定制一樣 變成一堆洞洞開不起來! 基礎建設(線路)出了問題 DNS引導你連到國外 那會是個災難 線路沒問題 DNS引導你連到國外 只是反應線路該有的延遲 & 較低的優先權 而不應該一堆東西開不出來 至少以前一直是這樣啦 XD 再來的部分是 各DNS解析的結果 其實FB/Akamai也要負點責任 因為大家都是用Anycast/EDNS Client Subnet等技術 照理說會直接提供用戶相對較近的CDN主機 至少像HiNet DNS這種的 使用的客戶多是HiNet等台灣地區ISP的用戶 明明台灣就有PoP 回應一個日本還是馬來西亞的PoP是怎樣 但FB/Akamai沒想到的可能是 台灣這段時間 尖峰連到國外某些地方的品質變得非常糟 XD 如前面所述 引導用戶到較遠的PoP 頂多就是網站開得慢一點 但不至於像HiNet非固定制這樣 一堆圖片開不出來 XDD 這部分可能要直接跟FB反應 看有沒有辦法做些什麼調整 因為HiNet/Google等DNS伺服器只會跟你說 他們是依照上游伺服器回傳的資訊 提供給下游用戶的 他們也沒辦法做些什麼 其實就網路架構而言是這樣沒錯 自己亂改、不忠實呈現上游DNS資訊的話 那不就跟中國一樣了 XDD 總結一下以上提到的「綜合問題」: 1. HiNet應該要把出國的網路連線品質弄好 這兩個月非固定制在尖峰下的表現非常糟 前幾天還有碰到 連imgur都打不開 鄉民PO文的貼圖都打不開 這像話嗎 XD 光是連線都有問題 別的就不用談了 就是在幫ISP下walkaround而已 雖然說 一分錢一分貨啦 不過最近好像真的很糟 以前不至於這樣 XD 2. FB/Akamai要調整好DNS設定 送給下一層DNS的IP 別老是離客戶太遠 一方面增加他們台灣PoP的利用率 同時ping值也好很多 用戶體驗好 廣告更賺錢 另一方面減少揹黑鍋的機率 XD 他們被罵得也很冤枉 因為設定沒弄好 應該只是延遲高一點 不至於頁面都是洞洞 開不出來 XD 對於原PO的話 你有幾個選項 XD 1. 換那高貴的固定制 這樣你優先權瞬間比幾百萬非固定制用戶要高 搶頻寬可以搶得贏別人 換成別人會更卡一點 XDD 2. 照三餐問候HiNet客服 看吵久了會不會有所改善 不過我覺得很難 XD 如果您或其它人有相關技術&知識 那還有其它選項: 3. 在台灣本島內找其它跳板連線出去 加上Proxy的.pac檔 裡面只設定連線狀況很差的主機走跳板 其它(多數都在台灣本島)都直接連線 可以節省頻寬的費用 像我有Google彰濱機房的VM 可以"借道"一下 順到爆炸是一定的 Google有自己的線路 XD 以前一次使用的狀況而言 我額外開了一台最小的VM來測試 用了40分鐘 列入計費的流量是29.8MB(小圖/縮圖流量不會很大) 小計為USD $0.003491 再加上VM本身&硬碟 全部加總為USD $0.007605 換成台幣為0.25元 夠便宜了吧 這金額連一通電話都打不了 但它可以解決我的問題 又不用急著換固定制 XDD 租一台機器 然後用完就關掉 不過要用這個要有些基本的相關知識 沒弄清楚規則的話 費用也是會破表的 XD 4. 既然DNS因故會導引到國外的PoP 也許寫隻script把那些受影響的機器的IP 寫死在hosts裡算了 讓它只會連到台灣的PoP 然後定期更新一下那些機器對應到台灣PoP的IP位址 XD 就在剛才(21:57) FB又開始一堆圖片變成洞洞 我先故意開某位朋友的FB 按一下會顯示他常出去拍的所有照片 全部打開應該有數千張 預設會先顯示一部分 捲到底會再多顯示一些縮圖 然後我把cache關掉 再重新整理頁面 先是一堆縮圖都開不出來 一堆洞洞 接著馬上使用我的.pac檔 改走HiNet固定制線路 建立連線後 馬上捲到最下面 讓它載入新的縮圖 (此時DNS cache未過期 所以我用的是HiNet DNS解析給我的IP位址 跟非固定制連到的主機是同一台) 結果新的縮圖馬上開始順暢載入 再往下捲又載入更多 屢試不爽 XD 然後回到頁面最前面 一開始還沒載入的圖片 還是卡在那邊 動彈不得 接著我再直接按下重新整理(此時還是cache關掉的狀態) 全部的縮圖依然順暢載入 再把跳板連線斷開 恢復成直接連線 再重新整理一次 一樣關掉cache 又有一堆縮圖開不出來了 XDD 大概是這樣 寫得有點亂 XD -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.116.167.84 ※ 文章網址: https://www.ptt.cc/bbs/Facebook/M.1445782048.A.793.html
推
10/25 22:23, , 1F
就還是無解....用不同瀏覽器也有不同結果
10/25 22:23, 1F
→
10/25 22:25, , 2F
不會呀 上面不是有說了嗎 你用跳板就有解啦 不過你要會
10/25 22:25, 2F
→
10/25 22:25, , 3F
操作就是 XD
10/25 22:25, 3F
→
10/25 22:26, , 4F
要不然就花錢換固定制就搞定 不過最近沒優惠 XD
10/25 22:26, 4F
→
10/25 22:28, , 5F
要不然就是把那些host的IP寫死 定期更新 但是會不會有
10/25 22:28, 5F
→
10/25 22:28, , 6F
副作用就不知道 XD
10/25 22:28, 6F
推
10/25 22:40, , 7F
所以樓主已經不用8.8.8.8、8.8.4.4了？
10/25 22:40, 7F
→
10/25 23:17, , 8F
是的 因為就我最近這一陣子持續觀察 它還是持續引導我連
10/25 23:17, 8F
→
10/25 23:17, , 9F
到國外 而且不只是縮圖會受到影響 是連其它主機都是 像
10/25 23:17, 9F
→
10/25 23:17, , 10F
是FB存放CSS等元素還有靜態物件的主機 都要我連到國外
10/25 23:17, 10F
→
10/25 23:18, , 11F
啊非固定制在尖峰的連線狀況就很糟呀 狀況更差的時候 我
10/25 23:18, 11F
→
10/25 23:18, , 12F
會連首頁的排版都亂掉 這不就更糟 同時也要讓更多流量走
10/25 23:18, 12F
→
10/25 23:18, , 13F
跳板 XD 我是Google DNS的長期使用者 從它公開IP位址後
10/25 23:18, 13F
→
10/25 23:18, , 14F
過幾個月就開始用 直到八月開始變這樣 當然你如果有看完
10/25 23:18, 14F
→
10/25 23:18, , 15F
我上面所說的 會發現其實不算是Google DNS的問題 XD
10/25 23:18, 15F
→
10/25 23:19, , 16F
它上游是FB/AkamaiDNS 連不出去也是HiNet非固定制線路爛
10/25 23:19, 16F
→
10/25 23:19, , 17F
目前改用HiNet DNS+固定制或是Google VM和適當的設定
10/25 23:19, 17F
→
10/25 23:19, , 18F
連線出去(目前只有縮圖需要走跳板 大圖&其它的都不用)
10/25 23:19, 18F
→
10/25 23:19, , 19F
要不然晚上都不要用網路了 XD HiNet非固定制走的線路真
10/25 23:19, 19F
→
10/25 23:19, , 20F
的問題不少 前幾天連imgur.com & 中國一些網站的圖片也
10/25 23:19, 20F
→
10/25 23:19, , 21F
開不出來 又是我一用跳板就秒開 真是氣死我了
10/25 23:19, 21F
→
10/25 23:20, , 22F
那個時間還是凌晨兩點 可不是什麼晚上九點熱門時段 XD
10/25 23:20, 22F
→
10/25 23:20, , 23F
我現在每個月再觀察一次 哪天狀況有改善會再換回來
10/25 23:20, 23F
→
10/25 23:21, , 24F
畢竟我比較相信Google對於相關技術的研究和投資 它的DNS
10/25 23:21, 24F
→
10/25 23:21, , 25F
設施同時給自己用 也幫人代管 也給一般客戶用 應該可靠XD
10/25 23:21, 25F
推
10/26 00:22, , 26F
!!!
10/26 00:22, 26F
→
10/26 00:22, , 27F
真的耶 改成固定ip 縮圖就順多了 但還是沒完全正常
10/26 00:22, 27F
→
10/26 00:23, , 28F
會有幾張沒顯示出來
10/26 00:23, 28F
推
10/26 00:36, , 29F
不... 後來發現其實沒順多少
10/26 00:36, 29F
→
10/26 00:47, , 30F
哈囉~您好像弄錯了 我說的不是「非固定制的固定IP」哦
10/26 00:47, 30F
→
10/26 00:48, , 31F
那個優先權是沒什麼差的 XD 我指的是這個 是要花錢的
10/26 00:48, 31F
→
10/26 00:48, , 32F
10/26 00:48, 32F
→
10/26 00:49, , 33F
沒花錢 哪來的優先權把別人擠下去 XD 另外 現在已經凌晨
10/26 00:49, 33F
→
10/26 00:49, , 34F
了 再晚一點 什麼也不用做 就會順暢許多 因為大家都睡覺
10/26 00:49, 34F
→
10/26 00:49, , 35F
了 競爭的人變少了 XDD
10/26 00:49, 35F
→
10/26 10:41, , 36F
明明台灣就有節點 硬是要繞去線路品質不佳的國外 XD ←
10/26 10:41, 36F
→
10/26 10:41, , 37F
不是ISP DNS能決定的，連到CDN主機後，伺服器會依據DNS
10/26 10:41, 37F
→
10/26 10:41, , 38F
自動判斷使用者的所在區域、分配給傳輸距離最近的邊緣伺
10/26 10:41, 38F
→
10/26 10:42, , 39F
服器，CDN服務業者會依其營運策略/流量/請求數去設定最
10/26 10:42, 39F
→
10/26 10:45, , 40F
佳化，所以解析結果還是會隨機變動的。其實用非固定制線
10/26 10:45, 40F
所以你好像沒看完我寫的 下面不就有說了嗎 XD ISP的DNS是夾心餅乾 真正該調整好的應該是FB/Akamai那邊 ISP的DNS如果自己修改的話 跟中國有什麼不同 XD
→
10/26 10:45, , 41F
路不一定會不順，IPv6其實就比IPv4順很多，用IPv6的人少
10/26 10:45, 41F
→
10/26 10:45, , 42F
IPv6伺服器流量負荷相對也小很多
10/26 10:45, 42F
非固定制優先權比其它低 這應該不用解釋 IPv6會比較順 應該是用得人比較少的假象吧 好像跟非固定制無關 XD 現在有多少網站預設是用IPv6? 但我知道的是 有些網站設定有問題 優先解析出IPv6的位址後 反而會連不上 要等它fallback老半天才行 因為用得人實在太少 根本沒什麼在測這塊 發現問題的速度也比較慢 XD 這樣繞過了一個問題 又有可能跑出其它問題 再者一堆國外網站還是沒有IPv6 像我前面說的imgur.com也遇到障礙 它也沒IPv6 台灣也沒cache/CDN(印象中沒看過) 但換條線路就很順 這種情況也幫不上忙 所以真正問題的根本就是 非固定制某些走的路線 這兩個月變很糟 DNS解析後連到國外伺服器 頂多只是開得慢一點 而不該連網頁物件都開不出來 其它的做法都只是在walkaround 而沒有解決真正的問題 就算FB/Akamai因故調整好相關資源 讓多數的request在台灣本島都消化完畢 其它網站呢? 還是要連線到國外的話 又會碰到一樣的問題不是嗎?
→
10/26 13:37, , 43F
請問，那換成「自動取得DNS伺服器位址」會好一點嗎？
10/26 13:37, 43F
→
10/26 13:47, , 44F
不一定，其實如果要從DNS設定方式來看的話，最好的情況可
10/26 13:47, 44F
→
10/26 13:48, , 45F
能還是以ISP業者的DNS伺服器位址會比較好些，至少對我來說
10/26 13:48, 45F
→
10/26 13:49, , 46F
目前設HiNet DNS比Google DNS要穩定得多，當然之前也有情
10/26 13:49, 46F
→
10/26 13:49, , 47F
況顛倒的時候啦，不過通常若發生時我就會多換幾組DNS伺服
10/26 13:49, 47F
→
10/26 13:50, , 48F
器測試看看
10/26 13:50, 48F
※ 編輯: jyhfang (122.116.167.84), 10/26/2015 16:03:27
→
10/26 16:16, , 49F
如果判斷是非固定制某些路由設定需要調整，由於去、回程
10/26 16:16, 49F
→
10/26 16:16, , 50F
路由通常不同，若僅看去程路由，多數情況下延遲其實都很
10/26 16:16, 50F
→
10/26 16:17, , 51F
正常，無法據此判斷是不是連外線路有障礙，除非是發生海
10/26 16:17, 51F
→
10/26 16:17, , 52F
正常，無法據此判斷是不是連外線路有障礙，除非是發生海
10/26 16:17, 52F
→
10/26 16:19, , 53F
纜障礙，尖峰時段+走長路由+非固定制沒有優先權，延遲會
10/26 16:19, 53F
→
10/26 16:24, , 54F
增加就比較難避免。如果有多個國外網站都這樣時，其實還
10/26 16:24, 54F
→
10/26 16:30, , 55F
是會建議要向HiNet客服反應一下.
10/26 16:30, 55F
→
10/26 19:02, , 56F
要把資料抓回來 不就是要去+回程都要暢通 資料才回得來
10/26 19:02, 56F
→
10/26 19:02, , 57F
嗎? 資料能傳回來 它怎麼走 一般人應該也不會很在意 頂
10/26 19:02, 57F
→
10/26 19:02, , 58F
多是延遲高了點 不該是圖片完全開不出來 現在FB會讓人
10/26 19:02, 58F
→
10/26 19:02, , 59F
很火就是這樣吧 XD 所以現在這樣 對用戶而言就是去+回
10/26 19:02, 59F
→
10/26 19:02, , 60F
程中間某些地方有障礙吧 要不然如何解釋 連到同樣的IP
10/26 19:02, 60F
→
10/26 19:03, , 61F
位址的伺服器 走不同路線就非常通暢 非固定制就是不通
10/26 19:03, 61F
→
10/26 19:03, , 62F
XD 我也常在尖峰時間連到一堆歐洲的網站 那邊的ping起
10/26 19:03, 62F
→
10/26 19:03, , 63F
碼是300起跳 雖然反應慢了點 但是慢慢傳 都會把資料完
10/26 19:03, 63F
→
10/26 19:03, , 64F
整的拖回來 而不是根本就開不出來 我可以開一堆分頁在
10/26 19:03, 64F
→
10/26 19:03, , 65F
背景 等一下再回來看就好 但FB就不是這樣 XD 如果再來
10/26 19:03, 65F
→
10/26 19:03, , 66F
有更多網站發生這種事 的確是會考慮向HiNet反應 不過因
10/26 19:03, 66F
→
10/26 19:03, , 67F
為目前有別的路線可以走 所以就再繼續觀察 畢竟時間寶
10/26 19:03, 67F
→
10/26 19:03, , 68F
貴 目前我一天只需花不到1元就可以繞開這個問題 XD 倒
10/26 19:03, 68F
→
10/26 19:04, , 69F
是其它沒別的路線可走的人 可以優先考慮一堆人一起反
10/26 19:04, 69F
→
10/26 19:04, , 70F
應 照三餐問候客服 看會不會比較有效
10/26 19:04, 70F
→
10/26 20:54, , 71F
http://is.gd/XzadvV 員工回應
10/26 20:54, 71F
看了一下 應該跟我看到的現象無關 : 我看看你設備到BRAS間是否有訊務過高的問題 如果這段路線已經過載 為什麼我用跳板連到其它地方就OK? 我有用跳板 or 沒使用 都會經過這段(設備到BRAS間) 如果這段有問題 我會連上其它網站都會卡死吧 XD : 他們表示FB的Akamai CDN業者不知為什麼把中華電信DNS發過去的詢問 : 導到國外的FB Server,所以開FB才會照片或圖無法顯示. 是的 這段的確FB/Akamai CDN要做調整 如我前面所述 一般會以EDNS Client Subnet等技術 把真正用戶的IP網段送給上游DNS 至少Google DNS說是這麼做的 HiNet可能也是 因此就算客戶人在DNS背後 不是直接連到FB/Akamai CDN，服務提供者還是知道真正客戶的大概位置在哪 接著引導客戶到比較近的伺服器 像現在沒弄好就會繞遠路 但繞遠路不代表圖片開不出來是合理的 頂多只是比較慢 像現在這樣就不正常 : 但如果用戶把自己家的DNS Server IP改由google的,就會正常 這個...XD 我前面也說過很多了 換成Google DNS 因為上游更會引導你出國 所以會突顯出線路方面的問題 相信有些人應該也有感覺到 改了沒變好 XD
推
10/26 22:27, , 72F
講出來不知道會不會害用這個擴充功能的人變慢 請餵狗
10/26 22:27, 72F
→
10/26 22:27, , 73F
zenmate vpn 使用方法很簡單
10/26 22:27, 73F
→
10/26 22:44, , 74F
讀取會變慢 但縮圖會正常顯示
10/26 22:44, 74F
這就是跳板呀 如果用了之後會正常顯示圖片 表示跟我看到的情況一樣 你換條路線就可以順利走到目的地 & 把資料傳回來 XD 不過用這種要小心 因為你不知道架這個的人心裡在想什麼 像FB/Google有https可能還好 你連進去之後 預設應該是本機所有流量都轉過去 其它沒加密的流量就有可能被看到! 所以如果會操作的話 自己開一台最小的Google VM就可以了 加上適當的設定 一天花不到1塊錢台幣 XD ================================== 我好像想到辦法了 這個把戲其實我一直用在別的地方 沒直接聯想到可以用在這 剛才23點尖峰時試了是可行的 XDD http://i.imgur.com/TL2OcUe.png
簡單來說 就是走HiNet自己的Proxy 而不是自己直接連線出去 這個東西我每週這個時間要大量傳檔案到中國都要這麼用 要不然上傳真的是慢到掉渣 XD FB使用HTTPS 連到這種Proxy就是下"CONNECT"指令 它會像個接線生一樣 透過它幫你建立連線 因為用的是https 所以代理伺服器無法動裡面流量的手腳 也無法先偷偷cache (有的話會被你發現 簽章驗證失敗) 所以不太需要擔心安全的問題 副作用的話可能會是 連到某些網站會比你直接連線來得慢 遇到這種情況再把Proxy關掉 或是使用.pac檔 只把會卡的網址的流量引導過去即可 猜測這樣可以動的原因 應該是HiNet的proxy若沒有針對特定網站調整設定的話 某些目的地的優先權可能比一般非固定制高 XD ※ 編輯: jyhfang (122.116.167.84), 10/27/2015 00:41:54
→
10/27 00:44, , 75F
現在尖峰時間過了 明天晚上可以再試試 XD
10/27 00:44, 75F
→
10/27 00:48, , 76F
另外 其它ISP我就不清楚了 別的ISP設定用HiNet Proxy的
10/27 00:48, 76F
→
10/27 00:48, , 77F
話 搞不好會變更慢 沒試過不確定 XD
10/27 00:48, 77F
※ 編輯: jyhfang (122.116.167.84), 10/27/2015 00:54:05
→
10/27 00:55, , 78F
設了Proxy之後 DNS用哪家就沒差了 因為你會把主機名稱交
10/27 00:55, 78F
→
10/27 00:56, , 79F
給代理伺服器 請他幫你建立連線 所以查IP的動作是在代理
10/27 00:56, 79F
→
10/27 00:56, , 80F
伺服器那邊做的
10/27 00:56, 80F
→
10/27 23:16, , 81F
剛才超卡 趕快試一下 結果跟我走Google線路差不多
10/27 23:16, 81F
→
10/27 23:16, , 82F
圖片都開得出來 XD 有遇到問題的HiNet用戶可以設定一下
10/27 23:16, 82F
→
10/27 23:16, , 83F
代理伺服器 應該會有改善 XD
10/27 23:16, 83F
→
11/03 15:20, , 84F
這幾天感覺FB瀏覽照片、顯示縮圖的錯誤率降低了，搞不好
11/03 15:20, 84F
→
11/03 15:21, , 85F
FB已經有做調整，可以把Proxy、DNS都還原到預設值試試看
11/03 15:21, 85F
推
11/04 12:44, , 86F
今天中午圖片不正常，況且今天是平常日
11/04 12:44, 86F
→
11/05 15:57, , 87F
是呀 這幾天的確比之前好很多 晚上尖峰沒那麼誇張了 XD
11/05 15:57, 87F
→
11/05 15:58, , 88F
不過同樣如樓上所說的一樣 昨天中午竟然出現類似現象
11/05 15:58, 88F
→
11/05 15:58, , 89F
中午耶!! 真是笑掉我的大牙 不知道又在搞什麼飛機
11/05 15:58, 89F
→
11/05 15:59, , 90F
昨天比較忙 沒去追蹤成因是否相同 下次來看看
11/05 15:59, 90F
‣ 更多 jyhfang 的文章
文章代碼(AID): #1MBE8WUJ (Facebook)
Facebook 近期熱門文章
更多 近期熱門文章 >>
PTT數位生活區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 jyhfang 的文章
文章代碼(AID): #1MBE8WUJ (Facebook)