I am trying to get around ISP limitations of 1 IP address. Here is what I am trying to do. I have two web servers running internally on my network. One is my main IIS box that runs 4 or 5 sites and I just added a windows home server. I have created a dns entry for it called home.mydomain.com and the other server reponds to www.mydomain.com.
My router is set to forward 80 to www.mydomain.com's server (192.168.1.3) so when requests come in for home.mydomain.com the request fails since www server is not set up to listen to that host header.
I would like to know if there is a way with IIS 7 to 'proxy' requests to home.mydomain.com (192.168.1.4). I had tried setting up HttpRedirect in IIS but that does not work as I would have hoped since it sends back a 302 to the client with a name that points back to the main IP address and then a vicious redirect loop happens.
I am told in apache this can be done by having one server proxy for the other. Can this be done in IIS 7? If not does anyone know of a webserver proxy type of software I can use?
Thanks in advance,
Rich
What you are looking for is a "reverse proxy". In Apache you can do this via mod_proxy. In IIS, you'll want to try the Application Request Routing package.
URL Rewrite for IIS can also be used to do reverse proxing.
Yet another reverse proxy package is Managed Fusion URL Rewriter and Reverse Proxy
Related
Let's say I have this DNS entry: mysite.sample. I am developing, and have a copy of my website running locally in http://localhost:8080. I want this website to be reachable using the (fake) DNS: http://mysite.sample, without being forced to remember in what port this site is running. I can setup /etc/hosts and nginx to do proxing for that, but ... Is there an easier way?
Can I somehow setup a simple DNS entry using /etc/hosts and/or dnsmasq where also a non-standard port (something different than :80/:443) is specified? Without the need to provide extra configuration for nginx?
Or phrased in a simpler way: Is it possible to provide port mappings for dns entries in /etc/hosts or dnsmasq?
DNS has nothing to do with the TCP port. DNS is there to resolv names (e.g. mysite.sample) into IP addresses - kind of like a phone book.
So it's a clear "NO". However, there's another solution and I try to explain it.
When you enter http://mysite.sample:8080 in your browser URL bar, your client (e.g. browser) will first try to resolve mysite.sample (via OS calls) to an IP address. This is where DNS kicks in, as DNS is your name resolver. If that happened, the job of DNS is finished and the browser continues.
This is where the "magic" in HTTP happens. The browser is connecting to the resolved IP address and the desired port (by default 80 for http and 443 for https), is waiting for the connection to be accepted and is then sending the following headers:
GET <resource> HTTP/1.1
Host: mysite.sample:8080
Now the server reads those headers and acts accordingly. Most modern web servers have something called "virtual hosts" (i.e. Apache) or "sites" (i.e. nginx). You can configure multiple vhosts/sites - one for each domain. The web server will then provide the site matching the requested host (which is retreived by the browser from the URL bar and passed to the server via Host HTTP header). This is pure HTTP and has nothing to do with TCP.
If you can't change the port of your origin service (in your case 8080), you might want to setup a new web server in front of your service. This is also called reverse proxy. I recommend reading the NGINX Reverse Proxy docs, but you can also use Apache or any other modern web server.
For nginx, just setup a new site and redirect it to your service:
location mysite.example {
proxy_pass http://127.0.0.1:8080;
}
There is a mechanism in DNS for discovering the ports that a service uses, it is called the Service Record (SRV) which has the form
_service._proto.name. TTL class SRV priority weight port target.
However, to make use of this record you would need to have an application that referenced that record prior to making the call. As Dominique has said, this is not the way HTTP works.
I have written a previous answer that explains some of the background to this, and why HTTP isn't in the standard. (the article discusses WS, but the underlying discussion suggested adding this to the HTTP protocol directly)
Edited to add -
There was actually a draft IETF document exploring an official way to do this, but it never made it past draft stage.
This document specifies a new URI scheme called http+srv which uses a DNS SRV lookup to locate a HTTP server.
There is an specific SO answer here which points to an interesting post here
I am not sure how to formulate my question but here we go:
I have 2 servers, one is the nginx reverse proxy and one is the app server.
In my app server, I am developing a simple http client using jerseyclient that will send a request to another server. I can do this now but the traffic goes from the app server and directly to the destination. Is it possible to it from the app server, passes through the reverse proxy server and goes to the destination?
And, is this design ok or is it an abomination?
nginx reverse proxy works only for requests outside your network.
To configure your system works as you described you have to configure firewall NAT or caching HTTP proxy like squid etc.
If you have no reasons why your servers should look as single computer - your configuration is OK.
I'm trying to come up with a solution where I can do the follow:
In my scenario there are 2 servers.
API1: Nginx + API Website
API2: Nginx + Staging Website
In order to check new version of API via mobileapp, I want to set my phone to use a proxy server (Should be API2), and only when the dest URL is https://api.test.com it will redirect it internally to localhost:6000.
Any ideas of how it can be done? I know Nginx does not support SSL Proxing, but maybe I'm wrong.
Thanks
Well,
Eventually I was able to accomplish that by using Apache Traffic Server which has been configured as a forward proxy while doing some map rules to redirect traffic from https to localhost:443/
But, I will be happy to hear some more ideas.
Thanks
I simply want both example.com and www.example.com to go to the same website. Currently we have just added a binding to each. This creates a problem for WCF which then breaks because it says it can only accept one http address.
Is there a better way to configure a site to accept addresses with or without 'www'?
this has to be changed in the dns using a host or a record.
You shouldn't be hosting a site on the root domain. Better approach here is to redirect traffic to the root (.example.com) to the correct site (www.example.com) using an HTTP 302.
The WCF service should only receive traffic on its single binding. Use DNS, HTTP redirection, or some Traffic management application/appliance to get traffic from multiple points to the correct one.
I have a running HTTP web application and I am facing problems to make it run over HTTPS.
I am thinking of bringing some HTTPS Proxy that accepts user requests and forward it to the HTTP web app.
What do you think of that? and How can I accomplish that?
Setting up stunnel is a no-brainer - and its available for Unix/Linux/Posix/MSWindows (you might have mentioned what OS you are using).
(Also you can run the program to encrypt or decrpyt, at the server or at the client side)
It's possible to run Apache Httpd (for example) using HTTPS and use mod_proxy_http as a reverse proxy to forward the requests to your existing HTTP server. Of course, for this to be of any use, you'd need the reverse proxy and the target server to be connected in such a way that connections cannot be sniffed or altered.
You may find that the existing server needs certain extra settings for it to be aware it's using HTTPS (for example, special Valves in Apache Tomcat to set the HTTPS flag to true).
Apache httpd reverse-proxy?