First configuration

​

What you will set up

1. Confirm the service is running
2. Confirm how clients reach SafeSquid (listen address)
3. Lock down who may use the proxy (Access restrictions)
4. Point a browser at the proxy and test
5. Add a simple content rule (Access Profiles)
6. Learn where to look when something fails (logs)

​

1. Confirm the service

/etc/init.d/safesquid status

​

2. Confirm listen address

• You should see at least one enabled listener (IP and port), often port 8080.
• If Listen is empty, SafeSquid falls back to LISTEN_IP / LISTEN_PORT in startup.ini.

• Each enabled Listen entry binds when the service starts. Adding or changing a Listen entry only takes effect after a service restart, not on a configuration save.

​

3. Lock down Access restrictions

1. Set Default Access Policy to Deny (recommended).
2. Leave Kerberos / SSO off for this first pass (add it later; see Authentication).
3. Add one Allow list entry for your office or lab network.

​

4. Point a browser and test

1. On a PC inside the allowed range, set the HTTP/HTTPS proxy to the appliance IP and listen port (for example 10.0.0.5:8080).
2. Browse to a simple HTTP site (or HTTPS if your clients already trust the appliance for inspection — skip HTTPS Inspection for day one if unsure).
3. Open Reports → Detailed logs. You should see your request with username (or anonymous), URL, and status.

​

5. Add a simple Access Profiles rule

1. Open Access Profiles → Default Policies (or Secondary Policies).
2. Add a DENY rule for a category you can test safely (or a specific host if categories are not ready yet).

​

6. When something fails

1. Note the time, client IP, and URL.
2. Search Reports → Detailed logs for filter_name and filtering_reason.
3. On a test network only, set System configuration → Send Debugging Headers To → CLIENT and inspect response headers in the browser. See Debug response headers.
4. Turn debugging headers back to NONE when finished.

​

How to verify

1. Confirm the service reports running before doing anything else — a Web UI you cannot reach means every later step is moot.
2. Confirm the Listen entry you expect is enabled, and that the service was restarted after any change — Listen entries only bind at service start.
3. Read the Allow list top to bottom before trusting it: first-match-wins means a broad entry above your intended one silently claims its connections, with no warning anywhere in the Web UI.
4. Generate one allowed and one denied request, and confirm both appear in Detailed logs with the outcome you expect.
5. Confirm Detailed logs attribute the Access Profiles block to Access Profiles rather than Access restrictions — the two sections produce different filter reasons, and confusing one for the other is a common early debugging mistake.

​

What to do next

• Authentication — Kerberos / SSO or System authentication so logs show real usernames
• Integrate LDAP — groups for policy
• HTTPS Inspection — decrypt HTTPS when your policy requires it (plan client trust carefully)
• SSqore and Categorize Web-Sites — category-based Access Profiles
• Application Signatures — tag client applications for policy
• SqScan or Clam antivirus — malware scanning
• Subscription — license and feed updates
• Architecture — how sections fit together

​

See also

• Full documentation index
• Daemon, service, and files