本地站点下线后URL重定向方案选型及优化咨询

Let’s break down your options here—you’ve got a clear need for flexible, maintainable redirects as your old on-prem site winds down, so let’s weigh each approach and talk about what might work best for you.

1. AWS S3 + CloudFront + Route 53 #

Pros #

• Serverless, low overhead: No EC2 instances to patch, monitor, or scale—AWS handles all the infrastructure maintenance for you.
• Global performance: CloudFront provides edge caching and low-latency access for users worldwide, plus built-in WAF protection for added security.
• Scalable rule management: S3’s static site redirects work for simple prefix matches, and for complex cases (like your app=myapp query parameter conversion), you can use CloudFront Functions or Lambda@Edge to handle URL rewrites. Adding new rules later is just a matter of updating these functions or S3 config.

Cons #

• Learning curve: If your team isn’t familiar with AWS, setting up S3, CloudFront, and Route 53 can feel overwhelming initially.
• Complex rewrite setup: The query parameter to path conversion you need isn’t natively supported by S3’s basic redirect rules, so you’ll need to add the CloudFront/Lambda layer to make it work.

2. HAProxy on Linux #

Pros #

• High performance: HAProxy is lightweight and optimized for high-concurrency HTTP/TCP traffic, making it great for handling lots of redirect requests.
• Flexible routing: Supports complex ACLs and regex matching, so it can easily handle your query parameter and path rewrite needs.

Cons #

• Server maintenance overhead: You’ll be responsible for patching the Linux server, monitoring uptime, scaling resources if traffic spikes, and backing up configurations.
• Less intuitive for HTTP redirects: While powerful, HAProxy’s configuration syntax is less straightforward than Nginx for HTTP-specific use cases like yours.

3. Nginx on Linux #

Pros #

• Familiarity advantage: You already have existing Nginx config experience that maps directly to your use case—this means you can get up and running quickly with minimal learning curve.
• Intuitive, flexible configuration: Nginx’s location blocks and variable support (like $arg_app for query parameters) make it trivial to build the exact redirect rules you need. Adding new paths later is as simple as adding a new location block and reloading the server.
• Strong community support: Troubleshooting or finding examples for edge cases is easy thanks to Nginx’s massive user base.

Cons #

• Server maintenance: Like HAProxy, you’ll need to manage the underlying Linux server—patching, monitoring, and scaling are all on your team’s plate.

Are There Better Alternatives? #

If you’re already comfortable with AWS, CloudFront Functions + S3/Route 53 is a stronger serverless alternative than basic S3 redirects. CloudFront Functions let you write lightweight JavaScript to handle complex URL rewrites (like converting ?app=myapp to a path segment) without the overhead of Lambda@Edge. This keeps your setup serverless while supporting all your redirect needs.

For teams already invested in Salesforce tools, there are Salesforce-native redirect tools, but these are overkill for your use case since you’re redirecting from an external on-prem site.

Final Recommendation #

• Go with Nginx if: You want a fast, low-friction setup (leveraging your existing config experience) and already have a Linux server maintenance workflow in place. It’s the most straightforward option for your specific redirect rules, and adding new paths later is trivial. Here’s a refined version of your existing config that’s optimized for redirects (instead of proxying):

  server {
      listen 80;
      listen 443 ssl;
      server_name customerRelationsSite.com;
  
      # Handle /eula/prodmanager?app=myapp → domain.salesforce.com/eula/prod/myapp
      location = /eula/prodmanager {
          resolver 8.8.8.8;
          if ($arg_app) {
              return 301 https://domain.salesforce.com/eula/prod/$arg_app;
          }
          # Fallback if no app parameter is provided
          return 301 https://domain.salesforce.com/eula/prod/;
      }
  
      # Add new redirect rules here as needed
      location = /otherPaths {
          return 301 https://othersite/newPath;
      }
  
      # Catch-all for any unconfigured paths (adjust as needed)
      location / {
          return 301 https://your-default-destination.com;
      }
  }
  

  This uses return 301 instead of proxy_pass which is more efficient for redirects (it sends a direct redirect response to the user instead of proxying the request).

• Go with AWS S3 + CloudFront if: You want to eliminate server maintenance entirely. While there’s an initial setup cost, it’s a hands-off solution that scales automatically and works globally. Just use CloudFront Functions to handle the query parameter conversion.

• Skip HAProxy: For your HTTP redirect-focused use case, Nginx is more intuitive and aligns better with your existing knowledge.

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