curl命令执行时如何绕过Location跳转并检测真实应用状态

Got it, let's tackle this problem. The issue you're seeing is that the SSO/authentication gateway sitting in front of your app is returning a 302 redirect before ever checking if the actual application server is up. That's why you get the same 302 whether you use credentials or not— the gateway doesn't care about the app's state, it just does its job of redirecting to the SSO service. Here are a few ways to work around this and check the real status of your app:

• Bypass the gateway by targeting the application server directly
  If you have network access to the underlying application server (not just the public gateway URL), send your curl request straight to its internal IP/hostname and port. This skips the SSO gateway entirely and hits the app directly, so you'll get the true HTTP status code (like 503, 404, or a connection timeout) if the app is down. Example command:

  curl -Ik http://<internal-app-ip>:<app-port>/GestionHeures --user username:Password
  

• Check for a dedicated health endpoint
  Most modern applications expose a health check endpoint (e.g., /health, /actuator/health for Spring Boot apps) that's designed specifically for monitoring. These endpoints often bypass SSO redirects, or the gateway will pass through the real status if the app is down. Try hitting it with:

  curl -Ik http://grid-net.gs.ec.ge.com/health --user username:Password
  

  If the app is down, this should return a non-302 status code like 503 Service Unavailable.

• Follow the redirect and inspect the final response
  Use the -L flag to follow the 302 redirect, and add -v for verbose output to see if the final SSO page indicates the app is unavailable. Sometimes the SSO service will show an error message if it can't reach the downstream app. Run this command:

  curl -ILv http://grid-net.gs.ec.ge.com/GestionHeures --user username:Password
  

  Look for keywords like "service unavailable" or check the final HTTP status code—if the app is down, you might get a 500 or similar from the SSO service instead of a login prompt.

• Try internal request headers to bypass SSO
  Some gateways are configured to let internal requests skip authentication checks. If you're accessing the app from within the corporate network, try adding a custom header that the gateway recognizes (check your gateway's documentation for the correct header). For example:

  curl -Ik http://grid-net.gs.ec.ge.com/GestionHeures --user username:Password -H "X-Internal-Request: true"
  

  This might bypass the 302 redirect and let you reach the actual app server's status.

To recap: the 302 is coming from the SSO gateway, not your application. The gateway isn't performing health checks on the downstream app, so it redirects regardless of whether the app is up or down. Using one of the methods above should help you get past the gateway and see the real state of your application.

内容的提问来源于stack exchange，提问作者Keshav Kalra