bug: 上游为域名的时候请求404

[kenneth-bro]

Current Behavior

请求的就一直404，如果上线为内网IP服务的没问题。经过多次尝试，发现要做域名静态改写？

Expected Behavior

不需要域名静态改写即可访问

Error Logs

No response

Steps to Reproduce

1、配置域名服务为上游
2、配置路由即可。

Environment

• APISIX version (run apisix version): 3.9.1
• Operating system (run uname -a): debian
• OpenResty / Nginx version (run openresty -V or nginx -V):
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info): 3.5.0
• APISIX Dashboard version, if relevant: 3.0.1
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):
• docker image: apisix:3.9.1-debian

[juzhiyuan]

Hi @kenneth-bro,

1. I didn't test APISIX 3.9.1 with the existing APISIX Dashboard because http://github.com/apache/apisix-dashboard is not actively maintained.
2. Can you try using APISIX directly? If it still doesn't work, check the APISIX logs and your backend logs to determine the source of the 404 error (APISIX or Backend).

[kenneth-bro]

Hi @kenneth-bro,  你好 ，

1. I didn't test APISIX 3.9.1 with the existing APISIX Dashboard because http://github.com/apache/apisix-dashboard is not actively maintained.我没有使用现有的APISIX仪表板测试APISIX 3.9.1，因为http://github.com/apache/apache/apisix-dashboard无法积极维护。
2. Can you try using APISIX directly? If it still doesn't work, check the APISIX logs and your backend logs to determine the source of the 404 error (APISIX or Backend).您可以尝试直接使用Apisix吗？如果仍然不起作用，请检查APISIX日志和您的后端日志以确定404错误的源（APISIX或后端）。

直接使用apisix是通过什么方式配置？dashboard不维护的话有没有其他的工具？ @juzhiyuan

[mikyll]

Hi @kenneth-bro

The default way to configure APISIX is by using the Admin API, which is a set of nice and clean REST APIs. You can find the documentation for the latest version here and for APISIX 3.9 here.

The APISIX Dashboard simply maps the Admin API calls to some nice TypeScript/JavaScript UI hosted on a Go web server, to facilitate the configuration. However, it's not the recommended way to manage APISIX (nor any API gateway in general, actually) because it's harder to maintain and to integrate in CI/CD processes 👀

There's also a third method, which is based on YAML manifests, but this needs APISIX to be deployed in Standalone Mode and won't use the Etcd database as the configuration center.

Side note: consider always using the latest stable APISIX release and keep it updated whenever it's possible 🙂

[kenneth-bro]

Hi @kenneth-bro

The default way to configure APISIX is by using the Admin API, which is a set of nice and clean REST APIs. You can find the documentation for the latest version here and for APISIX 3.9 here.

The APISIX Dashboard simply maps the Admin API calls to some nice TypeScript/JavaScript UI hosted on a Go web server, to facilitate the configuration. However, it's not the recommended way to manage APISIX (nor any API gateway in general, actually) because it's harder to maintain and to integrate in CI/CD processes 👀

There's also a third method, which is based on YAML manifests, but this needs APISIX to be deployed in Standalone Mode and won't use the Etcd database as the configuration center.

Side note: consider always using the latest stable APISIX release and keep it updated whenever it's possible 🙂

@mikyll 使用API管理不直观且具备的能力要求较高，所以这个方式肯定不会优选吧

[bzp2010]

If your upstream has to be accessed by a domain, I think you may be using some kind of LB that will pass the domain name to discover some kind of “virtual server”, which only allows access to a specific backend through a specific domain name.

So when configuring your APISIX upstream, make sure pass_host is configured correctly, or if your upstream domain is fixed, just use rewrite and configure its value to upstream_host. https://apisix.apache.org/docs/apisix/admin-api/#request-body-parameters-4

According to the default configuration of APISIX, if you don't configure anything, the domain name that the client sends to the gateway itself will be passthrough to the upstream, not the one you configured in the upstream node.

When APISIX establishes a connection to the upstream, the domain name will be resolved to an IP, and the domain name in the upstream node will not overwrite the original one in the request unless you specifically configure it.

---

The API is easy to integrate with various external systems to automate management routes, if this is not an option then you will need an API wrapper to manage configurations, this could be https://github.com/api7/adc to enhance your ability using a bundle of YAML files. Easy to integrate with CI pipeline.