@Rocky If I enable the FE Proxy component for HTTP Stream Load, can I let query clients use the FE Proxy or should I steer them directly to the FE service itself ?

No, you should not use the FE Proxy for query clients. You should steer query clients directly to the FE service (typically on port 9030). The FE Proxy component is a specialized reverse proxy (based on Nginx) designed specifically to handle the HTTP Stream Load workflow, particularly in Kubernetes environments. Here is why you should keep them separate: 1. Protocol Compatibility * FE Proxy: Only supports HTTP traffic. Its primary job is to resolve the "307 Redirect" issue during Stream Load. When a client sends a load request to an FE, the FE redirects the client to a BE. In Kubernetes, that BE address is often an internal pod IP that external clients can't reach. The FE Proxy intercepts this and proxies the data to the internal BE IP. * Query Clients: Use the MySQL wire protocol, which is a non-HTTP, stateful TCP protocol. The FE Proxy does not support or proxy MySQL protocol traffic. 2. Connection Management * Query clients (standard SQL) connect to the FE's Query Port (default 9030). * The FE Proxy typically listens on port 8080 (in Helm/Operator setups) and handles traffic destined for the FE's HTTP Port (default 8030). Recommendation * For Stream Load: Point your

curl

or loading tools to the FE Proxy service (port 8080). * For Queries (SQL): Point your BI tools, applications, or MySQL clients to the FE service (port 9030). * If you need load balancing for queries across multiple FEs, you should use a dedicated MySQL-aware load balancer like ProxySQL, a cloud-native LoadBalancer (like AWS ELB/NLB) pointing to port 9030, or the JDBC

loadbalance://

connection string. References • introduction/Architecture.md • administration/management/resource_management/Load_balance.md • faq/operation_maintenance_faq.md

@Rocky This remains true even if my query client are going to use HTTP queries rather than MySQL ?

Yes, you can use the FE Proxy for HTTP-based SQL queries (the HTTP SQL API), but whether you should depends on your network environment and why you enabled the proxy in the first place. Here is the breakdown of how to steer your query clients based on the protocol they use: 1. For HTTP SQL API Clients If your clients are using the HTTP SQL API (typically on port 8030), the FE Proxy (typically on port 8080) will work as a standard reverse proxy. * When to use FE Proxy: In Kubernetes environments, if the FE Proxy is the only component exposed to the outside world (via a LoadBalancer or NodePort) to facilitate Stream Load, you can and should use it for your HTTP queries as well. It will forward the request to the FE, and since standard

SELECT

queries do not involve the "307 Redirect" to a BE, the proxy simply acts as a pass-through. * When to go direct: If your query client is inside the same network as the StarRocks cluster (e.g., another pod in the same K8s namespace), you should steer them directly to the FE Service (port 8030) to avoid the unnecessary overhead and latency of an extra Nginx hop. 2. For MySQL Protocol Clients Do not use the FE Proxy. The FE Proxy is an Nginx-based HTTP proxy. It does not support the MySQL wire protocol. Even if your client is "sending queries," if it's doing so via a MySQL driver (JDBC, Go-MySQL, etc.), it must connect directly to the FE Service on port 9030. Key Differences at a Glance Client Type | Direct to FE Service (Port 8030/9030) | Via FE Proxy (Port 8080) Stream Load (HTTP) | Fails if client is outside K8s (due to 307 Redirect to internal BE IPs). | Recommended for external clients. HTTP SQL API | Best for internal clients (low latency). | Good for external clients if already exposed. MySQL Protocol | Required (Port 9030). | Incompatible (Protocol mismatch). Summary Recommendation If you have query clients that strictly use the HTTP SQL API and they are coming from a network where the FE's internal IPs are unreachable, steering them to the FE Proxy is a valid and supported approach. For all other query scenarios, especially standard SQL tools using MySQL drivers, you must point them directly to the FE service. References • sql-reference/http_sql_api.md • administration/management/resource_management/Load_balance.md • introduction/Architecture.md References • administration/management/resource_management/Load_balance.md • introduction/Architecture.md • faq/operation_maintenance_faq.md • administration/management/logs.md