302 - Found
HTTP 302 Found means the resource is temporarily at a different URI and clients should follow Location for now.
Last reviewed: February 14, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Found Mean?
The resource is temporarily redirected, so clients should follow the current Location without treating it as permanent canonical migration.
Common Causes
- -Authentication middleware redirects unauthenticated sessions to login endpoint as temporary navigation behavior.
- -Traffic experiment framework sends cohort users to alternate path using cookie-based temporary redirect rule.
- -Reverse proxy switches to maintenance landing page during rollout window and issues temporary redirects.
How to Fix Found
- 1Validate temporary redirect targets and ensure they resolve correctly for the active route conditions.
- 2Set cache headers to prevent clients and intermediaries from treating temporary redirects as permanent.
- 3Remove stale or conflicting temporary routing rules that create loops or misdirected traffic.
Step-by-Step Diagnosis for Found
- 1Capture original method/URI plus
Locationand cache headers for every 302 emission. - 2Trace conditions that trigger redirect rules (auth state, feature flag, maintenance toggle, traffic steering).
- 3Inspect client behavior differences for method handling and automatic follow policies.
- 4Retest with redirect handling set to manual and automatic modes to confirm expected outcomes.
Temporary Redirect Rule Trigger Analysis
- -Inspect conditional routing logic (example: unauthenticated session redirected to temporary login bridge endpoint).
- -Validate rule expiry and ownership (example: maintenance redirect remained active after incident closure).
Client and Cache Behavior Validation
- -Check cache directives on 302 responses (example: intermediary caches temporary redirect too aggressively).
- -Compare client redirect semantics (example: some legacy clients alter method on 302 unexpectedly).
Implementation Examples
curl -i -X GET https://api.example.com/v1/resource
# Response:
# HTTP/1.1 302 Found
# Location: https://api.example.com/v1/temporary-resourceconst response = await fetch('https://api.example.com/v1/resource', {
method: 'GET',
headers: { 'Accept': 'application/json' },
redirect: 'manual'
});
if (response.status === 302) {
console.error('Handle 302 Found:', response.headers.get('location'));
}import requests
response = requests.get(
'https://api.example.com/v1/resource',
headers={'Accept': 'application/json'},
allow_redirects=False
)
if response.status_code == 302:
print('Handle 302 Found', response.headers.get('Location'))Seen in Production
Temporary maintenance route still active after recovery
Frequency: common
Example: API remains on temporary 302 to status page because rollback toggle was never reset.
Fix: Expire maintenance redirect flags automatically and gate closure with post-incident smoke tests.
A/B steering policy loops for one cohort
Frequency: rare
Example: Traffic bucket rule alternates between two temporary locations and causes repeated 302 chain for subset of users.
Fix: Add redirect-loop detection in rule evaluation and canary-test cohort routing changes before full rollout.
Debugging Tools
- -curl -IL to inspect redirect hops and Location headers
- -Browser DevTools Network tab (Preserve log enabled)
- -CDN and reverse-proxy access logs
- -Redirect-chain checks in CI
How to Verify the Fix
- -Confirm 302 appears only for intended temporary scenarios and resolves to the correct destination URI.
- -Validate users and API consumers reach final endpoints without redirect loops or stale redirect caches.
- -Check redirect frequency over time to ensure temporary rules automatically wind down as planned.
How to Prevent Recurrence
- -Attach expiration and owner metadata to temporary redirect rules so they are reviewed and removed on time.
- -Monitor temporary redirect rates per route and alert on unexpected spikes or long-lived growth.
- -Prefer 307 or 308 when strict method preservation is required for write-safe client behavior.
Pro Tip
- -govern temporary redirects as feature flags with enforced TTL so emergency routing rules cannot silently become permanent architecture.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.