# Nginx Server Block Diagnosis: Served vs Edited Mismatch

## Diagnostic Signal

You edit a file on disk, verify the edit is correct with `grep` or `read_file`, but the user reports the fix didn't work. Using `curl -sk https://localhost/page.html | grep 'fix-pattern'` returns empty — the fix is NOT in the served content.

## Root Cause Pattern

Multiple nginx server blocks can serve the same domain on different ports. `sites-available/` and `sites-enabled/` may contain **different files with different directives** — not simply symlinks.

In this session:
- `/etc/nginx/sites-available/shopproquote` had `listen 3448 ssl` with aggressive caching (`expires 30d; Cache-Control: public, immutable`)
- `/etc/nginx/sites-enabled/shopproquote` had `listen 443 ssl` with NO caching headers and different `location` blocks
- The files were **different regular files**, not symlinks

## Diagnosis Steps

```bash
# 1. Check what's actually enabled
ls -la /etc/nginx/sites-enabled/

# 2. Compare enabled vs available
diff /etc/nginx/sites-available/<name> /etc/nginx/sites-enabled/<name>

# 3. Check which port each server block listens on
grep -rn 'listen' /etc/nginx/sites-enabled/

# 4. Check the root directive
grep -rn 'root' /etc/nginx/sites-enabled/<name>

# 5. Check if any other enabled site uses the same port (conflict)
grep -rn 'listen.*PORT' /etc/nginx/sites-enabled/

# 6. Verify served content matches disk content
curl -sk https://localhost/page.html | grep -c 'your-fix-pattern'
# Should return ≥ 1. If 0, the file on disk isn't what's being served.
```

## Common Scenarios

| Symptom | Likely Cause |
|---------|-------------|
| Curl shows fix, user doesn't see it | Browser cache |
| Curl doesn't show fix, disk has it | Wrong server block / root path |
| Curl shows OLD fix but not NEW one | File not saved, or nginx not reloaded |
| Port 443 vs port 3448 content differs | Two different server blocks, different `root` |
| JS loaded but HTML not updated | Static asset caching (see Browser Cache Busting) |