HTTP Proxy Configuration

Before You Begin

You will need:

• A running Tymeslot instance deployed inside a corporate network
• The hostname, port, and (if required) credentials for your corporate proxy
• Access to your Tymeslot instance's environment variables

By the end of this guide, Tymeslot's outbound HTTP and HTTPS requests will go through your corporate proxy.

When You Need This

This guide is for corporate or restricted networks where policy blocks servers from reaching the internet directly. Most self-hosted deployments on a home server, VPS or cloud VM do not need a proxy; if your server can reach the internet directly, skip this guide.

Tymeslot makes outbound connections to the following external services. If one is unreachable, the feature that depends on it fails, silently or with a connection error:

• Google OAuth endpoints (login and token refresh)
• Google Calendar and Google Meet APIs
• Microsoft OAuth and Microsoft Graph API
• GitHub OAuth (if GitHub login is enabled)
• CalDAV servers, Zoom, Telegram and outgoing webhooks
• Google reCAPTCHA verification endpoint

1 Configure the Proxy

Set the proxy with environment variables. Tymeslot reads both uppercase and lowercase names; if both are set, uppercase wins:

# HTTPS proxy: outbound API calls (OAuth, calendars, video, reCAPTCHA)
HTTPS_PROXY=http://proxy.corp.example.com:3128

# HTTP proxy: plain-HTTP requests (rare, but some networks need it)
HTTP_PROXY=http://proxy.corp.example.com:3128

# Bypass list: hosts that must not go through the proxy
NO_PROXY=localhost,127.0.0.1,::1

Tymeslot reads these variables only at startup, so restart it after setting them. On boot, the log line HTTP/HTTPS proxy configured for outbound requests lists the proxies and bypass list it picked up. Email is not sent through the proxy: SMTP and the email API providers (Postmark, SendGrid, Mailgun, AhaSend) connect directly, so your firewall must let Tymeslot reach your mail provider.

2 Authenticated Proxy

If your proxy requires credentials, put them in the proxy URL using standard URL syntax:

HTTPS_PROXY=http://username:password@proxy.corp.example.com:3128

URL-encode any special characters in the password. For example, a password containing @ must be written as %40.

3 Configure the Bypass List

NO_PROXY is a comma-separated list of hosts that bypass the proxy. It accepts these patterns, plus a lone * to bypass the proxy for every host:

An example combining all three:

NO_PROXY=localhost,127.0.0.1,::1,10.0.0.0/8,192.168.0.0/16,*.internal.example.com

TLS-Inspecting Proxies (MITM Proxies)

Some corporate proxies inspect TLS: they terminate the HTTPS connection, inspect the traffic, then open a new TLS connection to the destination and present a certificate signed by their own CA. If your proxy does this, Tymeslot rejects every HTTPS connection, because it does not trust that CA.

The symptom is certificate verification errors in the Tymeslot logs even though the proxy URL is correct. Tymeslot trusts the system CA bundle at /etc/ssl/certs/ca-certificates.crt and ignores SSL_CERT_FILE, so add your corporate CA to that bundle and mount the result over it:

# Copy the image's CA bundle and append your corporate CA (PEM format)
docker cp tymeslot:/etc/ssl/certs/ca-certificates.crt ./ca-bundle.crt
cat corporate-ca.crt >> ca-bundle.crt

# docker-compose.yml snippet
services:
  tymeslot:
    volumes:
      - ./ca-bundle.crt:/etc/ssl/certs/ca-certificates.crt:ro

Your network or security team can provide the CA certificate, usually as a .crt or .pem file. The mounted bundle replaces the image's own, so rebuild it after image updates to keep the public CAs current.

Testing Proxy Connectivity

Before restarting Tymeslot with the new proxy settings, check that the proxy accepts connections from your Docker network. The Tymeslot image does not include curl, so run it in a throwaway container on the network the bundled Compose file creates:

docker run --rm --network tymeslot_network curlimages/curl \
  -sv -x http://proxy.corp.example.com:3128 https://www.google.com 2>&1 | head -30

Expected result: the output includes CONNECT www.google.com:443 followed by HTTP/1.1 200 Connection established and then Google's own response (a 200 or a redirect). That confirms the proxy tunnel is open and HTTPS traffic flows through it.

Then check a real Tymeslot flow: restart the application with the proxy variables set and connect a Google or Outlook calendar. If the connection completes and the calendar's events appear, Tymeslot is reaching the provider's API through the proxy.

Troubleshooting

❓ Frequently Asked Questions

Verification Checklist

• HTTPS_PROXY is set to your corporate proxy URL
• NO_PROXY includes localhost, 127.0.0.1, and ::1
• The curl test returns 200 Connection established followed by Google's response
• If using a TLS-inspecting proxy: corporate CA certificate mounted and trusted inside the container
• Tymeslot restarted after the variable changes, and its startup log shows the proxy configuration
• A Google or Outlook calendar connects and shows its events