# Proxy with server\_name

**URL:** <https://community.nginx.org/t/proxy-with-server-name/9729>\
**Category:** NGINX\
**Tags:** reverse-proxy\
**Created:** [June 16, 2026, 3:45am UTC](https://community.nginx.org/t/proxy-with-server-name/9729 "2026-06-16T03:45:44Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![xlf](https://avatars.discourse-cdn.com/v4/letter/x/e5b9ba/32.png) [@xlf](https://community.nginx.org/u/xlf)\
**Post date:** [June 16, 2026, 3:45am UTC](https://community.nginx.org/t/proxy-with-server-name/9729/1 "2026-06-16T03:45:44Z")

</div>

Can I use `proxy_pass https://127.0.0.1` to proxy to a `server` that has `server_name`? If I use the `server_name` like `proxy_pass https://example.com` then I need a `resolver` which I don’t want to set up.

I want to use `https` instead of `http` in `proxy_pass` because the server I’m proxying is using SSL.

Does someone have an example of how to use unix sockets for this?

---

<div class="post-metadata">

**Author:** ![FrancisD](https://avatars.discourse-cdn.com/v4/letter/f/ea5d25/32.png) [@FrancisD](https://community.nginx.org/u/FrancisD)\
**Post date:** [June 18, 2026, 4:46pm UTC](https://community.nginx.org/t/proxy-with-server-name/9729/2 "2026-06-18T16:46:26Z")

</div>

Hi there,

The proxy\_pass docs are at [http://nginx.org/r/proxy\_pass](http://nginx.org/r/proxy_pass) . That shows how to use a unix socket as the upstream service (proxy\_pass [http://unix](http://unix):/tmp/backend.socket:/uri/;).

If you use “proxy\_pass [https://example.com](https://example.com);”, you don’t need a within-nginx resolver – nginx will either read the “upstream [example.com](http://example.com) {}” configuration block to find “server” addresses, or will use the system resolver at load time to resolve [example.com](http://example.com) (and will not re-resolve while running).

But if the issue is that you want to validate the certificate presented by the proxied upstream server, or you want to send the correct SNI header to that proxied upstream server, then you can use “proxy\_pass [https://127.0.0.1](https://127.0.0.1);” but you will almost certainly want to add proxy\_ssl\_name ([http://nginx.org/r/proxy\_ssl\_name](http://nginx.org/r/proxy_ssl_name)) and maybe proxy\_set\_header ([http://nginx.org/r/proxy\_set\_header](http://nginx.org/r/proxy_set_header)) with “Host” for consistency.

Cheers,

---

<div class="post-metadata">

**Author:** ![xlf](https://avatars.discourse-cdn.com/v4/letter/x/e5b9ba/32.png) [@xlf](https://community.nginx.org/u/xlf)\
**Post date:** [June 23, 2026, 3:17am UTC](https://community.nginx.org/t/proxy-with-server-name/9729/3 "2026-06-23T03:17:12Z")

</div>

The issue is I want to proxy without using a `resolver`. It would work if I only had one `server` block because it would always proxy to that one but if I have many `server` blocks with different `server_names` it won’t work because `proxy_pass` needs to know which one to use.

Is there a way to do it without a resolver? Unix sockets can be one way if it works.

---

<div class="post-metadata">

**Author:** ![FrancisD](https://avatars.discourse-cdn.com/v4/letter/f/ea5d25/32.png) [@FrancisD](https://community.nginx.org/u/FrancisD)\
**Post date:** [June 24, 2026, 3:33pm UTC](https://community.nginx.org/t/proxy-with-server-name/9729/4 "2026-06-24T15:33:57Z")

</div>

Hi there,

there are (at least) two ways to do it without using any external resolver.

You can “proxy\_pass” to the ip:port, and “proxy\_set\_header host” the appropriate name; or you can “upstream” the appropriate name with “server” to define the ip:port, and then “proxy\_pass” to the upstream-name, letting the default values of “proxy\_set\_header” be used.

Demonstrating both: this config snippet is in one nginx “http” block that defines three server{}s listening on 127.0.0.1:8080 identified by server\_name plus two upstream{}s that “resolve” some names to ip:ports. It also has one server{} listening on 8088 that will proxy\_pass to another server{}, depending on the incoming request.

Each server{} returns some content indicating the block and request that was used.

```auto
    upstream one {
        server 127.0.0.1:8080;
    }
    upstream two.example.com {
        server 127.0.0.1:8080;
    }
    server {
        listen 127.0.0.1:8080;
        server_name one one.example.com;
        return 200 "server $server_name\nhost $http_host\nrequest $request_uri\nuri $uri\n";
    }
    server {
        listen 127.0.0.1:8080;
        server_name two two.example.com;
        return 200 "server $server_name\nhost $http_host\nrequest $request_uri\nuri $uri\n";
    }
    server {
        listen 127.0.0.1:8080;
        server_name three three.example.com;
        return 200 "server $server_name\nhost $http_host\nrequest $request_uri\nuri $uri\n";
    }

    server {
        listen 8088;
        server_name main.example.com;

        location ^~ /one/ {
            proxy_pass http://one;
        }
        location ^~ /two/ {
            proxy_pass http://two.example.com/;
        }
        location ^~ /three/ {
            proxy_pass http://127.0.0.1:8080;
            proxy_set_header host "three.example.com";
        }
        location / {
            return 200 "ok\n";
        }
    }

```

With that, you can see if the output that you get, matches the output that you expect, from the commands:

```
$ curl http://localhost:8088/zero/
$ curl http://localhost:8088/one/
$ curl http://localhost:8088/two/
$ curl http://localhost:8088/three/

```

(Note that the extra / at the end of one proxy\_pass is intentional, to show how that matters.)

If the upstream services are https not http, the other directives mentioned previously might matter too.

Cheers,

---

<div class="post-metadata">

**Author:** ![system](https://drob5swvtjqxg.cloudfront.net/user_avatar/community.nginx.org/system/32/19_2.png) [@system](https://community.nginx.org/u/system)\
**Post date:** [July 24, 2026, 3:34pm UTC](https://community.nginx.org/t/proxy-with-server-name/9729/5 "2026-07-24T15:34:46Z")

</div>

Closed on July 24, 2026, 3:34pm UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.