以下故事由真實故事改編，如有雷同純屬巧合。(？)
為保護當事人，以下將會做適度的改編。
本文開始
回想起來，距今大概也有幾年的時間了吧。
在產品經歷了無數次的alpha與beta測試，最後即將上線的前夕的時候曾經發生這麼樣的一個事件：這個事件造成數十個工程師與QA不眠不休的努力，經歷無數小時的苦悶掙扎、有歡笑有淚水(只有最後)，最終才得以解脫的悲慘事件。如果當初早點知道443 port背後所代表的意義，或許我們這些苦命的攻城獅全部都可以早點回家洗洗睡了……
首先，在這個事件當中主要有三個單位涉及其中：營運方RD人員、營運方QA人員與我們這些負責研發的攻城獅。
事件的難解有很大一部份的原因就在這裡，因為，我們完全沒有任何權限去調查與更動已佈署在營運方的任何程式碼與設定。
我們必須要憑空想像出所有可能的原因，並依賴營運方的QA人員進行對應的操作。
死線就在眼前。
原本的產品預定的上線時間就在BUG發生的前幾天；這個BUG所涉及的功能非常重要，可以說是整個產品的生命線。而這個功能不管在alpha或beta測試環境都非常完美的運作，可是，卻在實際要運作的上線環境發生問題。
到底發生了什麼事？我們猜想是營運方某個對應api的設定檔設置錯誤，然而對方也在懷疑是我們的程式寫錯……於是，鬼打牆的戲碼就這樣開始上演了。
三方溝通是一件非常耗費心神的事，想要確認任何的東西都需要透過大量的陳述，想辦法說服對方說確認這件事是有助於解決問題的；有時第一次的要求並不會很快的就得到回應，必須一而再、再而三的重複強調之後事情才有可能得到答覆。這期間的無力感是非常重的，因為必須要想辦法提出正確的問題與『問法』，才有辦法得到希望的答案。
我們不斷的比較沙箱環境與上線環境的log，最後發現了下面這個可疑的api：
為什麼正式環境要帶個443 port？而把這串api直接丟上瀏灠器上卻直接回應一個bad request(400)。至少該給我一個權限不足(403)之類的訊息吧？正式環境的網址是對的嗎？當我把這個疑問向營運方提出的時候，對方卻說那是正常的，內部機制會自動加上443，我們不用去關心細節。
自動加上443？為什麼要做這件事？有什麼意義嗎？
嗯……不過被回答不用去關心他們內部細節的話，當然我也無話可說，也只能乖乖的繼續尋找其他可能的線索。
就當大家在接近要放棄狀態，準備延後產品上線時間的時候，我們內部的一位伺服器專家突然冒出一句話：「一般443走https SSL不是http」──這時，我們才驚覺原來問題點一直就放在眼前。
是的，問題就這樣被解決了。
當我們要求營運方將正式環境設定的網址加上一個s之後，世界就如同往常一樣的美好。
心得：有時候多知道一些東西，可以幫助自己用正確的問法問出正確的答案。
此bug的受害者：
營運方1個RD 4個QA
我方4個RD
共9人與3個爆肝日
解決方案：加上一個s
C子
身為美術人，看到這篇後開始對工程師抱持敬意
dorgon
: )
barneybook
443是https，不是常識?
dorgon
不是吧~這東西至少我是在經歷過這段之後才知道的。
現在技術的東西太多，其實也沒辦法每個東西都知道。
每個人都有他自己的專攻
另外這裡debug的難度在於你看不到全部的資訊，必須要跟對方進行溝通……
Anonymous
HTTPS預設443 port真的是常識～
Anonymous
常識無誤
dorgon
不好意思，我沒常識QQ
barneybook
應該說網站開發的部分，應該也要了解一些環境的架設與設定
這樣才不會容易卡在這類的問題上
dorgon
這裡面有很大的一個問題在於443是營運方server內部在轉送到其他server的時候『自動』加上去的(悲劇的原因)，外部設定介面設http看起來很正常沒什麼不對……
Che-Yu Lee
https的預設port就是443,不需要再加port號…
就跟你http也不用再特別加個:80一樣的道理
dorgon
不，是營運方的內部code自己加的
原本預期那邊走的是http而不是https
我們也很訝異為什麼log拿出來會多個443 port…
Anonymous
…我要笑了噗吃～ 但細節決定成敗 有時就是敗在自己認為最簡單的事 而忽略了它
dorgonman
有些無奈是要實際經歷過才知道的阿……
Nick
有遇到过同样的问题 哈哈