摘要：故事的經過是這樣的有一天，產品同學突發(fā)奇想，他想獲取到下單用戶的地理位置分布，以便來統(tǒng)計用戶群的分布，進而為后期的按地區(qū)精確推廣活動來做準備。

大家好，我是冰茶，容我開場先講個故事。
故事的經過是這樣的：

有一天，產品同學突發(fā)奇想，他想獲取到下單用戶的地理位置分布，以便來統(tǒng)計用戶群的分布，進而為后期的按地區(qū)精確推廣活動來做準備。

me：這個簡單啊，下單的時候，給個地理定位的請求，來獲取用戶所在位置就行啊，這樣的話還準確......

產品兄：這個方案需要考慮下，如果要是請求用戶的定位信息，首先呢，可能會引起用戶的反感，畢竟咱們這個產品，從頭到尾都沒有用到過定位，突然啪的一下來個彈窗，用戶肯定一是蒙逼，說你從頭到尾都沒有定位功能，要個定位權限有毛用，二是隱私意識強點，就直接拒絕掉了，這樣直接就拿不到信息，無法達到預設的效果了。其次呢，咱們能少打擾用戶，就少打擾用戶，有句話說，悄悄地進村，打槍的不要。就是說呢，讓用戶流暢的使用下來整個流程，讓用戶用的爽，一直是咱們的原則......

產品兄：我聽說有個IP定位，這東西蠻爽的，也不打擾用戶，再說IP這個東西，只要用戶訪問我們的服務，絕對有這個東西能拿到，我們就拿他這個東西來反查下，這樣咱們要的省市信息就這樣到手了，而且這樣的成功幾率高，不用擔心用戶拒絕定位導致數(shù)據(jù)統(tǒng)計不全......

后端同學：IP這個東西的確可以，但是呢，我們的服務都在負載均衡/反向代理服務后面，后端直接拿到的IP也是前端服務器的IP，而不是用戶直連我們前端服務器的IP，所以這個東西難辦啊~

后端同學：想當初我們的項目還不是前后端分離的時候，的確是可以直接拿到IP的......

另外的前端同學：嗯，我這邊也了解一些，我之前看到有前端獲取IP的方法：

//創(chuàng)建RTCPeerConnection接口
let conn = new RTCPeerConnection({
        iceServers: []
    }) 
let noop = function(){}
conn.onicecandidate = function(ice){
    if (ice.candidate){
        //使用正則獲取ip
        let ip_regex = /([0-9]{1,3}(.[0-9]{1,3}){3}|[a-f0-9]{1,4}(:[a-f0-9]{1,4}){7})/
        let ip_addr = ip_regex.exec(ice.candidate.candidate)[1];
        console.log(ip_addr)
        conn.onicecandidate = noop
    }
}
//隨便創(chuàng)建一個叫狗的通道(channel)
conn.createDataChannel("dog")
//創(chuàng)建一個SDP協(xié)議請求
conn.createOffer(conn.setLocalDescription.bind(conn),noop)

作者：Illgo
鏈接：https://www.zhihu.com/question/20675353/answer/335325619
來源：知乎
著作權歸作者所有。商業(yè)轉載請聯(lián)系作者獲得授權，非商業(yè)轉載請注明出處。

之后用 WebRTC獲取IP 等關鍵詞找了幾篇類似的文章。這個比較全面。

獲取訪問者內網(wǎng)IP

根據(jù)類似的文章，親自試驗了下，有兩個問題：

我們有微信站的業(yè)務，在微信環(huán)境下獲取不到IP。這個方法在Chrome和Firefox下面很好用。

獲取的是用戶的內網(wǎng)IP，用拿到的IP去反查，得到的結論是局域網(wǎng)地址。

這還查個毛線的查，于是......這個方案被放棄了......

me：在Google找了一些方案，大多數(shù)方案都是通過前端調取一個接口，接口返回地理定位等信息。和后端同學說的一致，只要用戶發(fā)請求，服務器能直接拿到用戶網(wǎng)絡出口的IP信息，然后咱們就調接口查一下就可以了。關于后端接口拿不到IP的問題，微信支付這邊有類似的解決方案。

備注：獲取用戶IP指引

me：咱們服務器相當于在代理后面，只要找運維去配置下，應該就可以了。

后端同學：這個可以考慮，稍后我這邊和運維聯(lián)系下，讓他們那邊配置下，把用戶請求代理服務器獲取到的IP傳遞給我這邊，這樣就可以了。

于是問題解決，大功告成~

開玩笑，要真是這樣的話，這篇文章就不會出現(xiàn)了