<p>I have a Kubernetes ingress that I want to be the default for all paths on a set of hosts, provided there is not a more specific match:</p>

<pre><code>apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: default-ing
spec:
  rules:
  - host: host1.sub.example.com
    http:
      paths:
      - backend:
          serviceName: my-default-service
          servicePort: http
        # Note: here we specify the root path intended as a default
        path: /
      - backend:
          serviceName: my-default-service
          servicePort: http
        path: /route/path/to/default
</code></pre>

<p>A second ingress defines a custom service for a specific path:</p>

<pre><code>apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: special-ing
spec:
  rules:
  - host: host1.sub.example.com
    http:
      paths:
      - backend:
          serviceName: special-service
          servicePort: http
        path: /special
</code></pre>

<p>I would expect that the order of adding/deleting the ingresses would not matter, or at least I could have some way of indicating that the <code>path: /</code> in <code>default-ing</code> is always to be ordered last.</p>

<p>When I try the above, the routing is fine as long as I add <code>special-ing</code> before <code>default-ing</code> (or alternatively, add <code>default-ing</code>, then the <code>special-ing</code>, then delete <code>default-ing</code> and re-add it again).  When I add them as <code>default-ing</code>, then <code>special-ing</code>, requests to <code>/special are</code> routed to <code>my-default-service</code> instead of <code>special-service</code>.</p>

<p>I want the order of adding/deleting to be independent of the routing that is generated by nginx-ingress-controller, so that my kubectl manipulations are more robust, and if one of the ingresses is recreated nothing will break.</p>

<p>I'm using <code>nginx-ingress-controller:0.19.0</code></p>

<p>Thanks for any help you can offer!</p>

<p>The short answer is no. I believe your configs should be disallowed by the nginx ingress controller or documented somewhere. Basically what's happening when you have 2 <code>hosts</code> rules with the same value: <code>host1.sub.example.com</code> one is overwriting the other in the <a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#server" rel="nofollow noreferrer"><code>server {}</code></a> block in the <code>nginx.conf</code> that your nginx ingress controller is managing.</p>
<p>So if your add <code>default-ing</code> before <code>special-ing</code> then <code>special-ing</code> will be the actual config.  When you add <code>special-ing</code> before <code>default-ing</code> then <code>default-ing</code> will be your only config, <code>special-ing</code> is not supposed to work at all.</p>
<ol>
<li><p>Add <code>special-ing</code>, and the configs look something like this:</p>
<pre><code>  server {
      server_name host1.sub.example.com;
      ...
      location /special {
                         ...
      }
      location / { # default backend
                  ...
      }
      ...            
 }
</code></pre>
</li>
<li><p>Now add <code>default-ing</code>, and the configs will change to like this:</p>
<pre><code> server {
      server_name host1.sub.example.com;
      ...
      location /route/path/to/default {
                                      ...
      }
      location / { # default backend
                  ...
      }
      ...
 }
</code></pre>
</li>
</ol>
<p>If you add them the other way around the config will look like 1. in the end.</p>
<p>You can find more by shelling into your nginx ingress controller pod and looking at the <code>nginx.conf</code> file.</p>
<pre><code> $ kubectl -n &lt;namespace&gt; exec -it nginx-ingress-controller-pod sh
 # cat /etc/nginx/nginx.conf
</code></pre>
<p>Update 03/31/2022:</p>
<p>It seems like on newer nginx ingress controller versions.  All the rules with the same host get merged into a server block in the <code>nginx.conf</code></p>
