http-proxy代理转发post
本文最后更新于：2023年3月21日 下午
2016-11-09 星期三 丙申年
[猴年] 己亥月 乙未日
宜：祭祀 祈福 求嗣 开光 解除
忌：嫁娶 进人口 入宅 移徙 出火
此工具在於使用nodejs的proxy代理轉發請求非get請求失敗而生；
在項目開發中，我們會前後端分離，各自進行開發，後端RD開發自己的；
前端FE開發自己的，只需要接口對上即可，在完成開發后，會進行聯調；
一般的做法是FE鏈接RD的開發機地址進行聯調接口，從而此問題就暴露了：
1.是不是只有get請求可以呢？
2.為啥非得非get請求怎麼都不行？
3.還是提交代碼到測試環境進行聯調吧。
累不累？痛不痛苦？
本來就是可以本地聯調的，幹嘛非得再搞一套？既然get請求可以，非get為啥不行呢？下面我們來揭秘：
據鄙人簡單分析，還未進入代碼階段：
1.請求沒有打到RD開發機上，那麼非GET請求怎麼可能成功？
2.請求打到了RD開發機上，但是後端報錯了；
3.代理請求工具有bug；
終上所述，無非就是這三個原因，那麼你猜猜，到底是那個原因呢？
大多數人會覺得不就是1麼，或者3？
回答得貌似有那麼積分道理，本質現象不就是這樣麼，後端本來就沒收到請求呀！
經過鄙人排查，實際上是2 和3同時出了問題；
原因：
請求實際上是打到了開發機上！
1.在發起非GET請求時，首先會先發送一個options請求進行第一次握手，如果驗證成功，那麼則進行正常的ajax請求，明顯在本地localhost：下區連接另一個IP是不肯能成功的嘛；
2.proxy代理工具也無法解決這樣的問題，本地配置host也沒辦法，配置host后是不是直接進入了127.0.0.1 ajax了呢？對吧？
基於這樣的原理，那麼換個思路：我們使用curl命令行操作它，思路來自nodejs支持子進程做一些想做的事情，
所以哐哐哐代碼就給擼上了~~~~
裡面有詳細的教程配置，如何使用……