Received a request today, the front desk needs to call the background SMS sending gateway: the parameters must be passed in the form of post, and the url of the request to send SMS in the foreground is inconsistent with the url of the SMS sent in the background
The url of the front desk is http://xxx.test.com/ajax/mobiledynamiclogincode
The url of the background sending SMS gateway is:
http://xxx2.test.com/json/account/mobiledynamiclogincode
analyze:
1. The rewrite in nginx to the external url will cause the loss of post parameters, so this solution is abandoned. (Internal rewrite will not lose post data)
reason:
(1) During post, the parameters are stored in the message body and passed. For the internal url transfer, because it is the same request, the message body (request body) does not change, so the post data will not be lost.
(2) For the external jump, it is actually a 302, that is, the user is requesting once, so the data of the first time will not be posted the second time.
The details are as follows: After you post the data, after matching the rewrite, because it is an external url, the user will see a 302, and then the requested url becomes get. . Then the data of the previous post is lost (because the user did not submit the data again)
2. You need to pass post parameters, you need to use proxy_pass. At the same time, because the url before the proxy is different from the url of the proxy, location needs to be done, and the full path needs to be written in proxy_pass. The reference example is as follows
I thought about why proxy_pass can pass the parameters of post: because for the user, it is just a request, so the request body has not changed. nginx will pass the request body to subsequent servers
location /ajax/mobiledynamiclogincode {
proxy_pass http://xxx2.test.com/json/account/mobiledynamiclogincode;
}
====================================================================
A few days ago, I set up a forum server and put it in the company's local area network. The forum uses port 9066 and made a port forwarding on the router, and also pointed the domain name bbs.xxx.com to the company's public network IP . Because I don't want users to enter the port number when accessing, I want to make a jump on the company's web server and transfer all requests to access bbs.xxx.com to his server. My first thought was to use nginx's rewrite. The process is very simple and the configuration is as follows:
server {
listen 80;
server_name bbs.xxx.com;
rewrite "^/(.*)$" http://bbs.xxx.com:9066/$1 break;
}
So I visited bbs.xxx.com and checked it. The operations such as registration, logging in, posting, etc. were all normal. I thought this was ok, but then the problem appeared. Although it can jump normally, the address on the domain name bar of the user's browser is The port number 9066 was followed all the time , which made the leaders very dissatisfied, so I found the nginx documentation and asked other friends in the group, there was no good way. So I switched to proxy_pass , and this configuration is also very simple:
server {
listen 80;
server_name bbs.xxx.com;
location /
{
proxy_pass http://bbs.xxx.com:9066/;
}
}
Then visit bbs.xxx.com and the port number behind it is gone. Registration, login, and posting are all normal, but after a while, there is a problem again. The user reports that the forum cannot be registered, and it prompts that " a single ip can only be registered 5 times a day. ", what's going on? After checking the log, I found that all the requests sent from the public network are actually the IP address of the gateway. Now I understand that after simply adding a proxy, if no further settings are made, nginx will not judge. The real client ip, but directly uses the routing address as the request ip, so the above situation occurs. After analysis, I checked the nginx wiki, so I added a few more:
server {
listen 80;
server_name bbs.xxx.com;
location /
{
proxy_set_header Host $host;
proxy_set_header X-Real-Ip $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_pass http://bbs.xxx.com:9066/;
}
}
After the modification, I reloaded nginx and found that the source ip in the log is already the real client address. Re-registering, logging in, and posting are all normal. After repeating many times, no problem was found, and the client was also normal.
http://storysky.blog.51cto.com/628458/486338/
http://h2ofly.blog.51cto.com/6834926/1320187/