Foreign key constraints are a kind of relation - a subset relation - but these aren't the relations from which the model derives its name. Rather, the relations of the relational model refer to finitary relations. Ted Codd wrote in his 1970 paper A Relational Model of Data for Large Shared Data Banks that "The term relation is used here in its accepted mathematical sense. Given sets S1, S2, ... Sn (not necessarily distinct), R is a relation on these n sets if it is a set of n-tuples each of which has its first element from S1, its second element from S2, and so on." Thus, he was describing a structure which can be represented by a table, if we follow some rules like ignoring duplicate rows and the order of rows (it's a set, after all).
Another common misunderstanding is that foreign key constraints represent relationships between entities. They don't. Relationships are represented as sets/tables of rows of associated values. The keys of two or more entities will be recorded together in a row, whether it's in an "entity table" or a "relationship table". Foreign key constraints only enforce integrity, they don't link entities or tables. Tables can be joined on any predicate function, foreign key constraints play no role here.
Most people learn database concepts from blogs, tutorials and answers ranked by popularity. Most people have never read a decent database book, let alone papers by the inventors and students of the relational model of data. Most programmers and corporations want to get the product released and have little time or appreciation for logic, theory and philosophy. It's an inherently complicated field - see Bill Kent's book Data and Reality for an exploration of this complexity. Thus, most of what you'll find on the internet are half-truths at best as people try to make sense of a difficult topic.
People are familiar with records and pointers, due to their prevalence in mainstream programming languages, and they certainly look and sound a lot like entities and relationships. If entities are represented by tables/records, attributes by fields/columns, then 1-to-1 / 1-to-many relationships between entities must be an association between records/tables, right? It's a simple idea, and that makes it difficult to correct. The popularity of object/relational mapping and object-oriented domain models derive from this simple idea (and from well-spoken and sociable authors, unlike the surly attitudes of some relational proponents) but also further entrenches it.
Peter Chen (author of The Entity-Relationship Model - Toward a Unified View of Data made some effort to be rigorous, distinguishing "entity relations" and "relationship relations". In his view, entities were real-world concepts which were represented in a database as values, and described via association of values in rows. Relationships between entities were similarly represented by association of values in rows. The E-R model's distinction between relationships and attributes is somewhat redundant (attributes are just binary relationships) and there's little benefit in distinguishing entity tuples from relationship tuples. In fact, I believe it serves to reinforce the confusion. It's superficial similarity to the older network model helped its adoption but also served to maintain the latter, as developers adopted new terminology while maintaining old practices.
Object-role modeling (aka NIAM, by Sjir Nijssen and Terry Halpin) does away with attributes and focuses on domains, roles and relations. It's more elegant than E-R and much closer to a true relational model, but its strengths (logical, comprehensive, move away from the network model) is also its weaknesses (learning curve, more complicated diagrams, less amenable as a vehicle for familiar techniques).
Ted Codd remarked in the paper mentioned above that "The network model, on the other hand, has spawned a number of confusions, not the least of which is mistaking the derivation of connections for the derivation of relations." This is as true today as it was then. The relational model which he described has since been built on by many others, including Chris Date whose book An Introduction to Database Systems is one of the most comprehensive sources on the topic.
I'm naming all these authors because one more opinion on either side isn't going to clear up your confusion. Rather, go to the sources and study them for yourself. Yes, it's hard work, but your efforts will be repaid in the quality of understanding you'll gain.
