摘要:反向代理簡(jiǎn)單解釋,用戶訪問(wèn)頁(yè)面,由轉(zhuǎn)接,轉(zhuǎn)到服務(wù)器端的內(nèi)部開(kāi)放端口不對(duì)外。
剛接觸的一個(gè)涉及實(shí)時(shí)通信的h5項(xiàng)目,前期開(kāi)發(fā)沒(méi)遇到什么大問(wèn)題,在pc端chrome調(diào)試都一切正常,用手機(jī)訪問(wèn)頁(yè)面時(shí),卻出現(xiàn)了一個(gè)問(wèn)題,node啟動(dòng)服務(wù)的命令行界面并沒(méi)有打印出用戶訪問(wèn)頁(yè)面的信息,也就是說(shuō)手機(jī)端的頁(yè)面沒(méi)有連接到websocket服務(wù),且本地計(jì)算機(jī)和手機(jī)是連的是同一個(gè)wifi,也就是說(shuō)網(wǎng)絡(luò)環(huán)境相同,那為何會(huì)造成本地調(diào)試可行,而手機(jī)訪問(wèn)又不能連接websocket服務(wù)呢?
在網(wǎng)上查找的各種資料,其實(shí)基本都與此問(wèn)題無(wú)關(guān),
最后突然想起前段時(shí)間做過(guò)的一個(gè)python項(xiàng)目,在linux搭建的環(huán)境為gunicorn+python+nginx , 而gunicorn充當(dāng)?shù)木褪且粋€(gè)啟動(dòng)python環(huán)境的角色,而gunicorn訪問(wèn)的是localhost+端口,再利用nginx做反向代理,這個(gè)項(xiàng)目非常類似,于是我想到了做nginx反向代理。
nginx反向代理簡(jiǎn)單解釋,用戶訪問(wèn)頁(yè)面,由nginx轉(zhuǎn)接,轉(zhuǎn)到服務(wù)器端的內(nèi)部開(kāi)放端口(不對(duì)外)。
問(wèn)題原因:
手機(jī)端進(jìn)入頁(yè)面時(shí)訪問(wèn)的是內(nèi)網(wǎng)ip,這時(shí)nginx能識(shí)別內(nèi)網(wǎng)ip,并轉(zhuǎn)到對(duì)應(yīng)的項(xiàng)目上,但是頁(yè)面js調(diào)用的socket= io("ws://內(nèi)網(wǎng)ip:3000"),并不能直接訪問(wèn)websocket,會(huì)先轉(zhuǎn)到nginx,再由nginx來(lái)訪問(wèn)websocket服務(wù),websocket所開(kāi)放的端口,相當(dāng)于內(nèi)部端口,并不能對(duì)外訪問(wèn)
解決辦法:
修改html的js,var socket = io("ws://內(nèi)網(wǎng)ip:81"); 這里的81并不是websocket的訪問(wèn)端口,而是nginx的訪問(wèn)端口
做反向代理(配置如下)
map $http_upgrade $connection_upgrade {
default upgrade; "" close; } upstream websocket { server localhost:3000; # 這里是websocket的訪問(wèn)端口 } server { server_name 192.168.33.174; # 這里是內(nèi)網(wǎng)端口 listen 81; location / { proxy_pass http://websocket; proxy_read_timeout 300s; proxy_send_timeout 300s; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; } }
配上wsServer.js
var app = require("http").createServer()var io = require("socket.io")(app);
app.listen(3000); // websocket訪問(wèn)的端口
var amount = 0
index.html
var socket = io("ws://192.168.33.174:81"); // 內(nèi)網(wǎng)ip+端口加粗文字
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://m.specialneedsforspecialkids.com/yun/105415.html
摘要:一些調(diào)試工具說(shuō)起手機(jī)端調(diào)試,相比大家都不陌生。能對(duì)手機(jī)進(jìn)行遠(yuǎn)程調(diào)試,能操作,打印輸出等。通過(guò)使用實(shí)現(xiàn)本地與遠(yuǎn)程調(diào)試器的通信。安裝各種虛擬機(jī)在電腦上進(jìn)行手機(jī)調(diào)試。服務(wù)端接收到手機(jī)發(fā)來(lái)的消息,把消息廣播給所有客戶端。 一些調(diào)試工具 說(shuō)起手機(jī)端調(diào)試,相比大家都不陌生。 由于手機(jī)瀏覽器沒(méi)有像PC端瀏覽器一樣有開(kāi)發(fā)調(diào)試工具,所以一般手機(jī)端的調(diào)試都要借助于電腦,現(xiàn)在的調(diào)試方式通常有以下幾種。 直...
摘要:中微信內(nèi)置瀏覽器還不支持我堅(jiān)信不久的將來(lái)就會(huì)支持,但在中能夠完美支持。因此本項(xiàng)目選擇了微信公眾號(hào)為切入點(diǎn),通過(guò)檢測(cè)引導(dǎo)用戶在中打開(kāi)頁(yè)面。為了便于傳輸可將其處理成字符串,另一端接收時(shí)還原并用對(duì)應(yīng)的構(gòu)造函數(shù)構(gòu)造對(duì)應(yīng)的實(shí)例即可。 前言 前段時(shí)間一直在忙一個(gè)基于WebRTC的PC和移動(dòng)端雙向視頻的項(xiàng)目。第一次接觸webRTC,難免遇到了許多問(wèn)題,比如:webRTC移動(dòng)端兼容性檢測(cè),如何配置Me...
摘要:前言作為一個(gè)消息代理客戶端與服務(wù)端的通信時(shí)基于協(xié)議的而現(xiàn)在的主流應(yīng)用時(shí)呈現(xiàn)在瀏覽器中這意味著用戶與服務(wù)端只能通過(guò)或者這類瀏覽器能理解的協(xié)議傳輸所以后端還要建立一個(gè)代理層將協(xié)議傳輸?shù)膬?nèi)容解析一下以協(xié)議發(fā)送到最后再由發(fā)送到硬件端在瀏覽器支持的協(xié) 前言 mosquitto 作為一個(gè)消息代理, 客戶端與 mosquitto 服務(wù)端的通信時(shí)基于 MQTT 協(xié)議的, 而現(xiàn)在的主流 web 應(yīng)用時(shí)呈...
摘要:前言作為一個(gè)消息代理客戶端與服務(wù)端的通信時(shí)基于協(xié)議的而現(xiàn)在的主流應(yīng)用時(shí)呈現(xiàn)在瀏覽器中這意味著用戶與服務(wù)端只能通過(guò)或者這類瀏覽器能理解的協(xié)議傳輸所以后端還要建立一個(gè)代理層將協(xié)議傳輸?shù)膬?nèi)容解析一下以協(xié)議發(fā)送到最后再由發(fā)送到硬件端在瀏覽器支持的協(xié) 前言 mosquitto 作為一個(gè)消息代理, 客戶端與 mosquitto 服務(wù)端的通信時(shí)基于 MQTT 協(xié)議的, 而現(xiàn)在的主流 web 應(yīng)用時(shí)呈...
閱讀 1600·2021-11-16 11:44
閱讀 7498·2021-09-22 15:00
閱讀 4532·2021-09-02 10:20
閱讀 1961·2021-08-27 16:20
閱讀 2402·2019-08-26 14:00
閱讀 2916·2019-08-26 11:44
閱讀 1648·2019-08-23 18:33
閱讀 1880·2019-08-22 17:28