If you haven’t already, emailing Hugging Face (website@huggingface.co) may get this looked at faster:
Your triage already looks strong. I would probably send this to Hugging Face as a Spaces outbound egress / networking issue, rather than spending much more time on SSL, requests, or Facebook-token debugging.
A practical route is:
website@huggingface.co- plus this forum thread, with redacted diagnostics attached
There is a forum answer mentioning website@huggingface.co for “website related problems / payment / feedback / specific problems” here: How can I contact with the Hugging Face team?
Direct framing
I would frame it roughly like this:
From this Space, TCP to graph.facebook.com:443 succeeds, but HTTPS requests consistently read-time out while waiting for the HTTP response payload. The same code path works locally. Could HF check whether this Space’s outbound egress path, NAT/proxy/firewall layer, DNS resolver, routing, or any intentional domain restriction is affecting graph.facebook.com?
That framing is useful because your evidence already narrows the problem quite a bit:
| Observation |
What it suggests |
TCP connect to graph.facebook.com:443 succeeds |
Not a simple DNS failure or immediate TCP block. |
verify=True and verify=False fail the same way |
Less likely to be a local CA/certificate verification problem. |
| Same code works locally |
Less likely to be pure app logic, token validity, or Facebook permission setup. |
| It worked about an hour earlier |
Runtime/egress/routing/edge/IP-reputation change becomes plausible. |
Failure is ReadTimeout, not a Graph API JSON error |
Less like normal app-level Graph API rate limiting. |
Target is HTTPS port 443 |
This is within the normal outbound port range documented for Spaces. |
HF’s Spaces docs say Spaces can make network requests through standard HTTP/HTTPS ports 80 and 443, plus 8080:
So the issue is not obviously “wrong port.” It is more likely somewhere around destination-specific egress behavior, shared NAT/proxy/firewall/routing, or how Meta treats the current HF egress path.
Why I would not over-focus on Facebook app settings first
It is still worth verifying the token and permissions locally, but the current evidence points away from that being the primary issue.
Meta’s Graph API rate-limit documentation says that once a rate limit is reached, subsequent requests fail and the API returns an error code until enough time has passed:
That does not rule out Meta-side WAF/anti-abuse/IP-reputation behavior, but it makes a plain app-level Graph API rate limit less consistent with a raw HTTP read timeout.
In other words, this does not look like:
Space -> Graph API -> structured Facebook error response
It looks more like:
Space -> outbound HTTPS path -> TCP OK -> HTTP response never arrives before read timeout
That is the part HF can investigate better than a Space user can.
Nearby HF forum context
This may also help HF classify the issue. There are nearby reports involving Spaces outbound access to social/automation APIs:
I would be careful not to claim these all have the same root cause. The failure modes differ. But they support the idea that destination-specific outbound behavior from Spaces is worth checking from HF’s side.
Suggested email subject
Spaces outbound HTTPS to graph.facebook.com: TCP succeeds but HTTP read-times out
Suggested email body
Hi Hugging Face team,
I am seeing what looks like a Hugging Face Spaces outbound egress issue affecting HTTPS requests to graph.facebook.com.
Summary:
- Space: <SPACE_URL_OR_NAMESPACE/SPACE_NAME>
- Started around: <UTC_TIME_WINDOW>
- Runtime / SDK: <Python/Gunicorn / Docker / Gradio / Streamlit / etc.>
- Python version: <PYTHON_VERSION>
- OpenSSL version: <OPENSSL_VERSION>
- HTTP client: requests / urllib3
- Hardware: <CPU Basic / upgraded CPU / GPU / ZeroGPU / etc.>
- Target endpoint: https://graph.facebook.com/
- Symptom: TCP connection to graph.facebook.com:443 succeeds, but HTTP response payloads consistently read-time out from the Space.
- The same code path and token work from local development.
- verify=True and verify=False behave the same, so this does not look like a local CA/certificate verification issue.
- Control domains such as https://api.github.com/ and https://www.google.com/ appear to work from the same Space. <adjust if not true>
I am not asking you to debug the Facebook token or application logic. The current evidence points to a Spaces outbound networking / egress path issue, or possibly Meta treating the shared Spaces egress IP/range differently.
Could you check whether:
1. graph.facebook.com is intentionally restricted from Spaces,
2. this Space is routed through a shared egress NAT/proxy/firewall with known issues,
3. the current egress IP/range has known problems reaching Meta / Facebook Graph API,
4. there is a cluster/node/egress-pool issue affecting outbound HTTPS to this destination,
5. the Space can be moved to a different egress path or otherwise refreshed server-side,
6. there is a recommended official route for reporting Spaces outbound egress issues.
Redacted diagnostics are below.
<PASTE_REDACTED_OUTPUT>
Thanks.
Minimal diagnostics worth attaching
Since you already checked the important pieces, I would keep the next diagnostic block focused and easy for HF to correlate with infra logs.
date -u
python --version
openssl version
echo "== DNS =="
getent hosts graph.facebook.com || true
getent hosts www.facebook.com || true
getent hosts developers.facebook.com || true
getent hosts api.github.com || true
getent hosts www.google.com || true
echo "== Python socket DNS/TCP check =="
python - <<'PY'
import socket, time
targets = [
"graph.facebook.com",
"www.facebook.com",
"developers.facebook.com",
"api.github.com",
"www.google.com",
]
for host in targets:
print(f"\n--- {host} ---")
try:
infos = socket.getaddrinfo(host, 443, proto=socket.IPPROTO_TCP)
print("DNS OK:", infos[:3])
except Exception as e:
print("DNS ERROR:", repr(e))
continue
try:
t0 = time.time()
s = socket.create_connection((host, 443), timeout=10)
print("TCP OK:", s.getpeername(), "elapsed=", round(time.time() - t0, 3), "s")
s.close()
except Exception as e:
print("TCP ERROR:", repr(e))
PY
echo "== curl target: graph.facebook.com =="
curl -v --http1.1 --connect-timeout 5 --max-time 30 https://graph.facebook.com/
curl -v --http2 --connect-timeout 5 --max-time 30 https://graph.facebook.com/
echo "== curl controls =="
curl -v --connect-timeout 5 --max-time 30 https://api.github.com/
curl -v --connect-timeout 5 --max-time 30 https://www.google.com/
curl -v --connect-timeout 5 --max-time 30 https://www.facebook.com/
curl -v --connect-timeout 5 --max-time 30 https://developers.facebook.com/
If you test an authenticated Graph API endpoint, redact tokens before posting anything publicly.
Optional requests check
This is useful mainly because it separates connect timeout from read timeout in a way that maps directly to your current finding.
import requests
import time
targets = [
"https://graph.facebook.com/",
"https://www.facebook.com/",
"https://developers.facebook.com/",
"https://api.github.com/",
"https://www.google.com/",
]
for url in targets:
print(f"\n--- {url} ---")
try:
t0 = time.time()
r = requests.get(url, timeout=(5, 20))
print("status:", r.status_code)
print("elapsed:", round(time.time() - t0, 3), "s")
print("headers_head:", dict(list(r.headers.items())[:10]))
print("body_head:", r.text[:300])
except Exception as e:
print("ERROR:", type(e).__name__, repr(e))
What to post publicly vs keep private
| Publicly useful |
Do not post publicly |
| UTC time window |
Facebook access tokens |
| Space URL or namespace |
App secret |
| Runtime / SDK / hardware tier |
OAuth authorization code |
| DNS result |
Page access token |
| TCP result |
Cookies |
curl -v with secrets redacted |
Full private business/page/ad account data |
| Control-domain comparison |
Private user data from logs |
| Local-vs-Space comparison |
Unredacted request URLs containing tokens |
How I would interpret the results
| Result |
Likely direction |
graph.facebook.com DNS fails |
DNS resolver / domain-policy / destination-specific DNS issue. |
| DNS succeeds but TCP connect fails |
Egress firewall/NAT/routing or destination-side TCP block. |
| TCP succeeds but TLS fails |
TLS/SNI/proxy/certificate path issue. |
| TCP/TLS succeed but HTTP read times out |
WAF/silent-drop/proxy/routing/edge issue. This seems closest to your report. |
Only graph.facebook.com fails |
Graph API-specific route/edge/policy issue. |
| All Meta domains fail |
HF-to-Meta path or Meta treatment of HF egress becomes more likely. |
| GitHub/Google also fail |
Broader Space outbound networking issue. |
| Duplicate Space works |
Node/cluster/egress-pool-specific issue. |
| Local dev fails too |
Facebook app/token/permission/API issue becomes more likely. |
If this blocks the app
For a short-term workaround, the most reliable architecture is probably to move the Facebook Graph API call out of the Space:
HF Space UI
-> small backend/proxy with controlled egress
-> graph.facebook.com
For example:
- Cloudflare Workers
- Google Cloud Run
- AWS Lambda
- Fly.io
- Railway
- Render
- a small VPS
This is not a criticism of Spaces. It is just a common pattern for OAuth / third-party API integrations where egress identity, retries, token handling, and audit logs matter.
For production-like use, I would keep:
| Responsibility |
Suggested place |
| UI / demo / admin surface |
HF Space |
| Facebook OAuth callback |
Backend service |
| Graph API calls |
Backend service |
| Token refresh and storage |
Backend service / secret manager |
| Retry/backoff/queueing |
Backend service |
| Audit logs |
Backend service |
Short thread update
If you want to keep the forum post concise, you could add:
I will also email website@huggingface.co with redacted diagnostics.
Current framing: this appears to be a Spaces outbound egress issue rather than an SSL/token/app-logic issue. From the Space, TCP to graph.facebook.com:443 succeeds, but HTTP response payloads read-time out. The same code/token works locally, and verify=True / verify=False behave the same.
I am asking HF to check whether this Space’s outbound egress path, NAT/proxy/firewall layer, DNS resolver, routing, or any intentional domain restriction is affecting graph.facebook.com.
Summary
- Your existing triage is already specific enough to escalate.
- I would email
website@huggingface.co and keep this forum thread updated.
- The strongest signal is: TCP OK, SSL verification irrelevant, local works, HTTP read timeout from Space.
- Ask HF to check egress/NAT/proxy/firewall/routing/domain restriction, not just app code.
- Keep all tokens, OAuth codes, app secrets, cookies, page tokens, and private IDs out of public posts.